Deciding How to Use PowerShell to Access AD DS

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, talks about the decision points for deciding how to use Windows PowerShell to access Active Directory Domain Services.  Hey, Scripting Guy! I am a bit confused. I see various blogs and scripts on the Script Repository, and some always use a third-party snap-in to access Active Directory Directory Domain Services (AD DS). Others seem to use .NET Framework code to access AD DS, and still others are using a module that looks like it is part of Windows PowerShell. What is the best way to access AD DS? —CB  Hello CB, Microsoft Scripting Guy, Ed Wilson, is here. This morning it is actually cool here in Charlotte, North Carolina. In fact, it is way cool because the Scripting Wife found a place on the Internet so she could order some chocolate covered Macadamia nuts. By the way, they go very well with Earl Grey tea with a cinnamon stick. The chocolate, the cinnamon, and the touch of bergamot combine to create an exquisite taste sensation. So, I am out on the lanai sipping tea, nibbling on chocolate covered Macadamia nuts and checking my email on my Surface RT, and I ran across this email to scripter@microsoft.com from CB.

Supportability—the big advantage

When comparing options for working with Active Directory Domain Services from within Windows PowerShell, one option stands above all the others: supportability. When I use the Active Directory module from Microsoft, it is supported. For me, this means a lot. So if something does not work out perfectly, I know it is supported. I gain access to the Active Directory module in two ways. On a domain controller that is running at least Windows Server 2008 R2, I add the Active Directory management feature, and I have access to the Active Directory module. I can access it locally on the server, or I can use remoting or implicit remoting to access the cmdlets from my workstation. For more information about remoting, see Use PowerShell Active Directory Cmdlets Without Installing Any Software. I can also install the Remote Server Admin Tools (RSAT) on my workstation. The version I install depends on the version of the operating system that I have on my workstation. For more information, see What’s Up with Active Directory Domain Services Cmdlets? Note  If I install Active Directory Management Service for Windows Server 2008, I do not get access to the Active Directory module on the server. I must install the RSAT tools on my workstation for management purposes. For more information, see Install Active Directory Management Service for Easy PowerShell Access.

Usability

In my mind, the cmdlets from the Active Directory module are easy to use. They are a little quirky, but after I get used to the quirks, they simply make sense. Therefore, to create a new user in an organizational unit (OU) named testou in the Iammred.net domain, I type the following:

New-ADUser -Name mynewtestuser -Path ‘ou=testou,dc=iammred,dc=net’
If I want to use the [adsi] type accelerator to create a new user, I type something like this:

$adsi = [adsi]”LDAP://dc=iammred,dc=net”

$de = $adsi.Create(‘user’,’cn=anothertestuser,ou=testou’)

$de.setinfo() One big problem with using this methodology (besides the fact that it is more typing and less intuitive), is the fact that tab expansion does not work properly. Therefore, some of the methods I want to use do not show up when I press the Tab key. The advantage, of using the [adsi] type accelerator is that I can use it no matter what version of Windows AD DS is running in. I do not have to have the AD Management service installed, nor do I need a server running at least Windows Server 2008 R2. If my domain meets the minimum guidelines for using the Active Directory module, there is really no decision—I can use the module and use the cmdlets. They are easy, and they are powerful. CB, that is all there is to using the Active Directory module. Join me tomorrow when I will talk about Windows PowerShell 3.0 in Windows 8. It is a way cool post, and a great way to continue your weekend. See you then. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy 

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow