6

All the PowerShell cmdlets in the ActiveDirectory module support being run against a specific domain controller using the -server parameter; but is there any way to set a default DC to use for all AD-related operations, or do I need to specify it on every single command if I actually care about which DC I'm using (as is frequent when replication latency is involved)?

  • Are you wanting to run commands on a distant DC, or always your closest? – Mark Henderson Jul 31 '13 at 9:52
  • I just want to make sure all commands always talk to the same DC, in order to avoid replication issues. Selecting the DC is not a problem, it will be provided in a variable. – Massimo Jul 31 '13 at 10:03
  • Also, in the same script(s) I'm running Exchange-related commands, and I need to make sure AD commands and Exchange commands are executed against the same DC. This is easy to do for Exchange (Set-ADServerSettings), but I can't find a way to do it for AD... – Massimo Jul 31 '13 at 10:04
  • Do you have your AD sites set up correctly? – longneck Jul 31 '13 at 11:40
  • Yes, but even with that, a different DC in the same site could be used by different commands. I'm not concerned about properly locating the nearest domain controller; I want to globally set which one all AD cmdlets should use. – Massimo Jul 31 '13 at 15:05
5

If you are on PowerShell version 3, then you can use the new automatic variable $PSDefaultParameterValues to set a default for the Server parameter on the AD Module cmdlets. You can run

Get-Help about_Parameters_Default_Values

for more details on this variable.

In your specific case, you could set the variable like so:

$PSDefaultParameterValues = @{"*-AD*:Server"='YOUR-CHOSEN-DC'}

Another option which would work with version 2 or 3, is to use the AD Module's provider to create a new PSDrive.

By default when you import the AD Module, it creates an "AD:" PSDrive which connects to the local domain. You can create new PSDrives using this same provider, specifying the specific domain controller you want to connect to. Then, when you run AD cmdlets from within the context of that PSDrive, they will use that connection. You can create a new PSDrive like so:

New-PSDrive -Name <name of the drive> -PSProvider ActiveDirectory -Root "<DN of the partition/NC>" –Server <server or domain name (NetBIOS/FQDN)[:port number]> -Credential <domain name>\<username>

Then just cd <name of drive>: and when you run your cmdlets, they will use the domain controller you specified in the New-PSDrive cmdlet.

  • I thought about creating a custom PSDrive, but I couldn't find any evidence whatsoever that it actually influences AD-related cmdlets. Proof: if I delete the default one with Remove-PSDrive AD, those cmdlets are able to run perfectly fine without having any "drive" defined. – Massimo Aug 5 '13 at 20:23
  • True -- AD provider drive is not required for the AD cmdlets to run, but IF they are called from within the context of one, that connection is used for the cmdlet. So if you create a new drive and use Set-Location (cd) to move to it, then the AD cmdlets will use the properties of that drive. – jbsmith Aug 5 '13 at 20:31
  • One drawback to @{"-AD:Server"='YOUR-CHOSEN-DC'} is that there can be other non-AD cmdlets that start the noun with "AD" such as the LAPS PowerShell cmdlets like Get-AdmPwdPassword. Right now those are the only ones I've found and fortunately there are no AD cmdlets that begin with "ADM" so I've worked around this by using "-AD[a-ln-z]:Server",$((Get-ADDomain).PDCEmulator) as my value which skips any cmdlet nouns starting with "ADM". I tried using just -AD[^m] in the construction but the negation didn't work, not sure why. – CitizenRon Aug 22 '17 at 19:35

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.