I need to know the logic behind AD cmdlets for deciding which server will handle the request.
The background is an temporary error message:
"A connection to the directory on which to process the request was unavailable. This is likely a transient condition."
I need to know which ADWS server is having the problem.
Note: i don't want to specify a server using the -Server property, i want to analyse the defect server
Try same with -verbose Switch. It should show you the connected DC.
Related
I want to check automatically the latest WindowsServerBackup result via PowerShell on Windows Server 2012/2012 R2.
It's not only "success" or "failure" but "backed-up volume" and "error message", too. So I tried using the following ways but I can't get the above informations.
Get-WB* is not enough that I want to do.
I can't find WMI object around WindowsServerBackup.
Get-Eventlog can't access about Backup (Application and Service Log/Microsoft/Windows/Backup)
Did I miss some right way? What should I do?
(Sorry. I'm not good at English.)
I am trying to create a powershell startup script for my domain controlled computers that will place the computer into the the specified OU. I would like for the variables to be taken on the local computer and then passed to the remote server. Once there I would like to execute the last two lines on the server.
The script below does work if it is ran on the server however as stated above I would like to be able to execute this from a client machine. How can I make this happen?
$computername = $env:ComputerName
$new_ou = "OU=TestOU,DC=Test,DC=Controller,DC=com"
Import-Module ActiveDirectory
Get-ADComputer $computername | Move-ADObject -TargetPath $new_ou
Note: Before anyone asks...my goal is to have the OU be determined by the client IP address. I understand that there are scripts that will do the discribed above but they run strictly on the server and query the DNS. I would rather have this run as a startup script on the local computer so I an better control which computers are being moved. At this point I am not interested in tackling this issue. Only the issue of how to execute the above lines on a local machine.
I assume you want to run the last 2 lines on the server because you expect that most of your domain computers won't have the RSAT tools or AD cmdlets installed.
The way to run it on a server is to have PowerShell Remoting enabled on the server and then use Invoke-Command.
That authentication is typically done with kerberos, though you could change the method, and you can supply credentials manually (though I doubt you want to be embedding credentials in the script).
You need to consider that the user making the AD changes needs permission to do so. Usually that's a domain admin, although permission could be delegated.
If you're running this as a startup script, it's running as SYSTEM. That account authenticates on the domain as the computer account (COMPUTERNAME$). This means that the computer account needs permission to move itself, which may mean it needs the ability to write objects into all possible OUs (I don't recall offhand which permissions are needed).
So you would either need to grant this ability to all computers (any computer in Domain Computers would have the ability to move any other computer to any OU), or somehow give each computer only the ability to move itself into the correct OU (which might still be too much in the way of permissions).
Another option is to make a customized session configuration on the server with a RunAs user. You could limit the users allowed to connect to the session (to Domain Computers), and limit the allowed commands so that the connecting computers can only run a limited set of functions/cmdlets. Even better, you can write your own function to do the change and only let them run that one. With the RunAs user being a privileged user in AD, the changes will work without the connecting user having the ability to make the changes directly, and without giving the connecting user the ability to use the privileged user or elevate their own permission. Remember that the connecting user in this case is the computer account.
This last method is, I think, the best/most secure way to do what you want, if you insist that it must be initiated from the client machine.
Reconsider doing this as a server-side process. Get-ADComputer can return an IPv4 address for the object, so you could use that instead of DNS. Centralizing it would make it easier to manage and troubleshoot the process.
How would I check if my credentials are already cached for a specific server using tf.exe? I am trying to do slight automation for tfs get and workspace/workfold configuration. The assumption is that most machines already have the credentials cached, but I want to be able to double check beforehand, and throw an error in powershell if they are not.
Thank you,
Derongan
Try using vaultcmd.exe e.g.:
vaultcmd /listcreds:"Windows Credentials" /all
You could run that through a Where-Object command looking for a string that matches the TFS server name.
I'm making a PowerShell script that will allow the user to move certain local files to a certain server. To ease the process I want to check if the user has access to the server or not, and if not, I want to prompt for a username/password.
Using Test-Path I can check whether or not the user can access specific remote location. However, if Test-Path fails, there is no way of knowing if it's because the remote location does not exist, or because the user does not have sufficient rights.
I'm looking for a way to:
Find out if the user has access to a remote location (could use Test-Path for this)
(if above failed) Find out if this is because the remote location is unavailable or because the user does not have sufficient rights
(depending on above) Show error message or prompt for credentials
Of course I could Test-Path, ask for credentials if necessary, and then Test-Path again. But I'm trying to find a nicer solution.
You can use Test-Connection to see if the server exists. This is not a fool-proof method though because not all servers and other devices that may be in the network path respond to ICMP requests, which is what Test-Connection and ping use.
I've recently upgraded a number of servers from 2003 to 2008R2. Since the upgrade I've started to see the following error:
[servername] Connecting to remote server failed with the following error message : The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.
The error is seemingly random. The script will work and then fail. The command to create the session is in a loop (create session, remove session) and is called numerous times as part of a set of deployment scripts. When the script fails, it fails at different points.
I've checked the event log on the local workstation (win7) destination server (win2008R2) but there are no errors that I can see.
This is the lines that randomly fails:
$session = New-PSSession -ComputerName $serverName -Credential $credential
I did not see this issue on Win2003. The scripts have not changed. I'm assuming the problem is on the destination server but cannot find any errors or logs to look at. It will work once and then fail so my deployment scripts will sometimes succeed and then fail at different points.
Any guidance on tracking down this problem would be much appreciated.
You can get this error when trying to connect to localhost with an account that's not an administrator.
It used to be possible to use accounts that weren't an administrator, but a Windows Update in January 2019 disabled the functionality for security reasons. From the patch notes:
By default, PowerShell remoting only works with administrator accounts, but can be configured to work with non-administrator accounts. Starting with this release, you cannot configure PowerShell remote endpoints to work with non-administrator accounts. When attempting to use a non-administrator account, the following error will appear:“New-PSSession: [computerName] Connecting to remote server localhost failed with the following error message: The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.”
You need to be setting the WSMan TrustedHosts. If you want, you can set it to everything using wildcards (*).
You can do it via PowerShell: Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.
Keep in mind that you also need to enable the Windows Remote service. Use the native winrm qc command for this. Enable-PSRemoting -Force might do it as well.
You can also use the PSExec Tools from Sysinternals. Keep in mind that these tools will likely be blocked by your EndPoint Security, so don't forget to white list it.
Is there a specific reason you migrate your old OSes to a newer, but still EOL OS? You can do a lot via PowerShell in 2008R2, but it's still pretty limited. IMO, Using PowerShell is best starting from 2012R2 and onwards.
Are you hitting the number of processes limit by creating pssessions that are crashing and leaving processes open?
Default limit is 15. I'd agree with the above comment and not use sessions, instead use invoke-command like:
invoke-command -scriptblock $scriptBlock -ArgumentList $args -computername $compName -Credential $encodedRemoteCredentials
to Check your limit:
PS C:\aws> ls WSMan:\localhost\Shell
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Shell
Name Value
---- ----
MaxProcessesPerShell 15
As a quick and dirty test - next time your pssession version of your script fails, increase the maxProcessesPerShell limit using set-item cmdlet to 50 and retry. If the script no longer fails, you know that's the issue (and should consider moving to invoke-command!).