I am new to power shell and I am trying to create a script that would create new users in Active Directory. Currently I am having trouble setting the Remote Desktop Services tab of the User. My code is below.
#Set Remote Control Settings Permissions
#I recieved Server is not operational error. https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/fail-to-configure-server-using-server-manager I think Invoke Set may not be the command I should use.
$userpath = dsquery user -samid $username
$userpat = "LDAP://$userpath"
$userp = [ADSI]$userpat
$userp.InvokeSet("EnableRemoteControl",2)
$userp.setinfo()
#Remote Desktop Services User profile profile path set to "\\documentsf\profiles\$username" THIS IS MESSING UP ERROR OCCURRS WITH INVOKE SET SAYING NOT SPECIFIED
$userp.InvokeSet("terminalservicesprofilepath","\\documentsf\profiles\$username")
$userp.setinfo()
The remote control permissions are a little strange and work best with the ADSI method, which you're close to already. dsquery actually returns a string with quotes inside it, so you'll either need to strip those quotes first or use a different method - I prefer Get-ADUser:
$LdapUser = "LDAP://" + (Get-ADUser $username).distinguishedName
$User = [ADSI]$LdapUser
$User.InvokeSet("EnableRemoteControl",2)
$User.setinfo()
And to set the remote desktop services profile path for a user:
$User.invokeset("terminalservicesprofilepath","\\Server\Share\$username")
$User.SetInfo()
Related
I've been trying to launch teams using powershell, i've succeeded launching teams using the destination path under the shortcut property, and then running it in powershell.
C:\Users\user1\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
But this only works for the local user, if i run the script with another user teams won't launch. i've storing the user in a variable.
$user = $env:UserName
C:\Users\$user\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
This doesn't work.
So my question how can I launch teams.exe (make it visible)?
I want to make it like how you can launch word with start winword.exe
You should get the variable for the App Data folder, not just the username. Otherwise, it won't work in situations where the user's profile folder is in a different location:
$user = "$($env:LOCALAPPDATA)\Microsoft\Teams\Update.exe --processStart `"Teams.exe`""
"%LOCALAPPDATA%\Microsoft\Teams\Update.exe" --processStart "Teams.exe"
This can be fixed by using the following format instead:
$user = $env:UserName
'C:\Users\'+$user+'\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"'
New to powershell but bear with me. I am trying to automate an install of Prosystem Fx Engagement, but need to install a SQL instance. I have already done this part, but I will also need to automate the changing of a services account within services.msc. It will need to be changed from "This account" to "Log in as Local System Account"
https://imgur.com/en9COWl
The name of the service is MSSQL$PROFXENGAGEMENT, and the display name of the service is SQL Server (PROFXENGAGEMENT).
I don't really want to use the method below because the password is visible on the .ps file. I tried looking around but was not able to find anything. Is this even possible?
$LocalSrv = Get-WmiObject Win32_service -filter "name='MSSQL$PROFXENGAGEMENT'"
$LocalSrv.Change($null,$null,$null,$null,$null,$false,"DOMAIN\administrator","PASSWORD")
As for the method you are saying you don't want to use for the account change activity. You don't have to and should not put plain text password in scripts.
You can prompt for the password, store that in a variable and use it. Yet, that means a human has to be there to address that, so, not very automated.
So, this means you need to set the credentials in a file or other store and call that from your script.
Meaning like what is described below. This of course has to be done in advance of any other use case that will need it.
using secure password with multiple users without prompt
#saving credentials
Get-Credential | Export-CliXml -Path c:\credential.xml
#importing credentials to a variable
$Credential = Import-CliXml -Path c:\credential.xml
A YouTube Video on the topic:
Learn to securely use Passwords with PowerShell
You could also use the Windows Credential Store, and call it from there. Also shown in the above video.
Using Windows Credential Manager
https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Credentials-d44c3cde
https://www.powershellgallery.com/packages/CredentialManager/1.0
https://www.experts-exchange.com/questions/29061982/Powershell-Using-credentials-stored-in-Credential-Manager.html
I have two different users, my regular user and my admin user. Both have profiles setup for PowerShell. I log into my workstation ONLY as my regular user. My issue is that when running PowerShell as my regular user, I can type "menu" at the prompt from any folder and it will run the Menu.ps1 script from the scripts folder. When I try running PowerShell as my admin user, I get "The Term 'menu' is not a blah blah blah". The only way I can run it is if I change the the PSDrive named scripts: and dot source execute from there.
The only difference that I can find is that my regular user has access to a windows mapped drive z: (its in the Path environment variable also), while my admin user does not. I was hoping that I would just need to add scripts:
to the environment variable but that didn't help either.
Any assistance is appreciated.
Thank You Jeff Zeitlin.
I added this to my Admin users profile, works perfectly.
$ScriptsPath = "\\Server\Share\Scripts"
$ScriptsDrive = "Z:"
$Network = New-Object -ComObject "Wscript.Network"
$Network.MapNetworkDrive("$($ScriptsDrive)","$($ScriptsPath)")
$strPath=$env:path
if (!($strPath.ToUpper().Contains($ScriptsDrive))) {
$env:path += ";" + $ScriptsDrive + "\"
}
As part of my current role, I frequently find myself having to work with objects in one of my organisation's resource forests. At the moment in order to do that, I use an RDP session connected to a server within that forest, and authenticate to it with a specific "Admin" account in that forest.
I'm starting to find this tedious, and so I've been trying to come up with a nice profile.ps1 which will get me a DirectoryEntry for the resource forest that I can work on with Powershell (v2.0) on my local workstation instead, and save me the tedium of constantly re-establishing RDP sessions.
So I've got some code in my profile.ps1 which looks like this:
$resforest = "LDAP://DC=ldap,DC=path,DC=details"
$creds = Get-Credential -credential "RESOURCE_FOREST\my_admin_account"
$username = $creds.username
$password = $creds.GetNetworkCredential().password
$directoryentry = New-Object System.DirectoryServices.DirectoryEntry($resforest,$username,$password)
All of this proceeds fine, however, when I come to actually use the entry thus:
$search = New-Object DirectoryServices.DirectorySearcher($directoryentry)
$search.filter = "(&(anr=something_to_look_for))"
$search.findall()
I get a logon failure.
Now, I know the credentials are fine, I can map drives with them from my workstation to machines in the resource forest - and that works fine - so what am I ballsing up here?
PS - Please don't ask me to do anything with Quest's AD cmdlets - they're not allowed here.
Turns out the issue was with the serverless binding I was attempting to do.
If I modify the LDAP path to "LDAP://ldap.path.details/DC=ldap,DC=path,DC=details" then everything works.
Thanks for everyone who at least looked at the question ;)
I am having trouble accessing a shared network location while within a PowerShell remote session.
From the PowerShell prompt, I enter a new session:
Enter-PSSession server1
The session is properly created and entered. I then attempt to list the contents of the share:
dir \\server2\share1
The response is this error:
Get-ChildItem : Cannot find path '\\server2\share1' because it does not exist.
However, if I remote desktop into server1, bring up PowerShell, and execute the very same dir command, the contents are correctly listed.
I've tried various things using credentials, but that doesn't seem to fix it. I've also confirmed via the "whoami" command that I have the same identity in both examples.
What would cause this?
If you can't use credential delegation as mentioned above, you can mount (or just authenticate as below) the remote share in the remote session using explicit credentials, e.g.
[server1] ps> net use \\server2\share * /user:username
(prompts for password)
[server1] ps> dir \\server2\share
(listing)
This problem has nothing to do with powershell per-se; you are trying to replay your local credentials in a remote session to a third location and falling foul of the NTLM "double hop" limitation.
Read the section "Credential Delegation"
Here - Credit to Keith Hill
and perform the steps if you have not already done so.
Another option is kerberos resource delegation
eg:
$server_name = "my-server" $servers = #(get-adcomputer -identity $server_name)
$target = "target-server" $tgt_srv = get-adcomputer -identity $target
Set-ADComputer -Identity $to_delegate -PrincipalsAllowedToDelegateToAccount $servers