Automating Active Directory mgmt in PowerShell

  • 423 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
423
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
  • MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Transcript

  • 1. Automating Active Directory Management in Windows PowerShell Don Jones ConcentratedTech.com Pre-requisites for this presentation: 1) Familiarity with AD administration 2) Basic understanding of how to use Windows PowerShell Level: Intermediate
  • 2. This slide deck was used in one of our many conference presentations. We hope you enjoy it, and invite you to use it within your own organization however you like. For more information on our company, including information on private classes and upcoming conference appearances, please visit our Web site, www.ConcentratedTech.com . For links to newly-posted decks, follow us on Twitter: @concentrateddon or @concentratdgreg This work is copyright ©Concentrated Technology, LLC
  • 3. About the Instructor
    • Don Jones
    • Contributing Editor, technetmagazine.com
    • IT author, consultant, and speaker
    • Co-founder of Concentrated Technology
    • Seven-time recipient of Microsoft ’s Most Valuable Professional (MVP) Award
    • Author and Editor-in-Chief for Realtime Publishers
    • Trainer for www.CBTNuggets.com
  • 4. About this Session
    • Primarily demo – not slides 
    • We ’ll start with some key functional concepts, and move right into the “how-to”
    • Bring your questions – anytime is the time to ask them! Don ’t save ‘em for the end.
    • We ’ll take a quick break halfway through
  • 5. Start Thinking
    • Since we ’re mostly doing demos, start thinking of AD administrative tasks you’d like to automate
    • I ’ll take your suggestions and construct some demos on the fly
  • 6. Cool…
    • I ’ll capture everything I type in the shell into a text file, and save all of my scripts
    • There ’s no need for you to copy down anything I do
    • It ’ll all be available for download from my Web site after the show
    • URL is on the last slide, and there are “reminder” cards if you’d like to take one
    • Now let ’s go…
  • 7. Requirements
    • Windows PowerShell v2
    • Windows 7 or Windows Server 2008 R2
      • PowerShell v2 is available back to WinXP
      • You need a Win7 or Win2008R2 machine to run the commands I ’ll be showing – at least one such machine in your environment
    • Compatible Domain Controller
      • Windows Server 2008 R2
      • Windows Server 2008 (w/Gateway Service)
      • Windows Server 2003 (w/Gateway Service)
  • 8. Gateway Service
    • The PowerShell AD commands “talk” to a Gateway Service
    • Ships with Win2008R2
    • Available for Win2008/Win2003 – you do not need a 2008 R2 domain controller
    • http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008940c6-0296-4597-be3e-1d24c1cf0dda
  • 9. Managing from Vista/XP?
    • No problem – get PowerShell v2 installed and I ’ll show you how you can use these older versions to run the AD commands
    • This ’ll come at the end
    • PowerShell v2: http://support.microsoft.com/kb/968929
      • Win2003, Win2008, WinXP, Win2003, Vista
      • Preinstalled w/Win2008R2 and Win7
  • 10. First: The AD Module
    • This module is installed with AD in Win2008R2, and with the RSAT on Win7
    • Import-Module ActiveDirectory
    • Adds a PSDrive provider an several dozen new cmdlets
    • Using it a lot? Put the Import-Module command into your PowerShell profile script
  • 11. Second: The AD: Drive
    • A drive (AD:) is automatically mapped to your logon domain
    • You can map additional drives to other domains
    • Change to the AD: drive and run New-PSDrive to do so
    • You can specify alternate credentials for the drive mapping
  • 12. What ’s the Drive For?
    • The drive is useful for managing ACLs using Get-ACL and Set-ACL
    • It ’s primary purpose, however, is to “remember” the credentials you used to map the drive in the first place
    • Whenever you are “in” an AD drive, any AD cmdlets you run will automatically use the drive’s credentials
    • Saves you from having to specify a –credential parameter for every command!
  • 13. Third: The AD Cmdlets
    • Let ’s see the cmdlets added by this module
    • They come with full help, including detailed usage examples
    • RTFM – The help is your friend!!!
    • Let ’s play with a few of these cmdlets to get a feel for how they work
    • Remember, you can always specify –credential, but if you ’re “in” an AD drive, it’ll use those credentials automatically
  • 14. Pipeline Input
    • Most AD cmdlets accept pipeline input, meaning you don ’t have to specify parameters – you can pipe data in
    • Each parameter can attach to pipeline input “ByValue” or “ByPropertyName”
    • Let ’s look at the differences with a very cool example
  • 15. ByPropertyName
    • This requires input objects ’ property names to match the parameter names
    • What if they don ’t?
    • Use Select-Object to copy an existing property to a new one having a matching name
    • Let ’s see another tres cool example
  • 16. Gotchas
    • New-ADUser ’s docs don’t say that –Name is required – it is
    • -samAccountName is not required – but it is. Let ’s see why.
  • 17. Gotchas
    • By default, most Get-AD* cmdlets only pull over a subset of attributes
    • Use the –property parameter (e.g., -prop *) to pull over more
    • This raises the load on the responding domain controller – use with some caution
    • Let ’s see
  • 18. Best Practice
    • Always use –filter to minimize what ’s brought back by a Get-AD* cmdlet (that’s why –filter is a required parameter)
    • Don ’t rely on –filter * in a production environment
    • -filter uses standard PowerShell comparison operators
    • Let ’s see
  • 19. Tip
    • If you don ’t know LDAP naming conventions, this is a good time to learn
      • CN = Canonical Name (user, group, container)
      • OU = organizational unit
      • DC = DNS domain name component
    • Cn=DonJ,ou=Sales,ou=West,dc=company,dc=com
    • Work from the more specific to the least specific (object to top-level domain)
  • 20. Pipeline Output
    • Many AD cmdlets don ’t normally produce output
    • -passThru forces them to output whatever object they created or whatever object was input
    • This enables powerful command chains – one liners that accomplish the work of a complicated script
    • Let ’s see!
  • 21. Passwords
    • Cmdlets which accept a password require it as a SecureString
    • Use ConvertTo-SecureString string –force to create a secure string
    • Let ’s see…
  • 22. Demos, Demos, Demos
    • Let ’s take some of your suggestions for demos
    • We ’ll also make sure we run through at least one quick demo for each major category of cmdlets
    • We ’ve got the time – so you’ll get to see how everything works
    • Remember, this is all going into a transcript and I ’m saving my script files – download URL at the end!
  • 23. Using an Older OS?
    • Provided you have:
      • A domain controller running the Gateway Service
      • At least one Win7 or Win2008R2 machine
    • You can use the AD commands on XP, Vista, 2003, and 2008 RTM
    • Using a feature called implicit remoting
    • Establish a PSSession remoting connection to the Win7 or Win2008R2 machine
    • “ Import” the AD commands from the remote machine
  • 24. Implicit Remoting
  • 25. Step 1
    • Establish a session to a remote machine that has the cmdlets
    • Tell the remote session to import the AD module
  • 26. Step 2
    • Export the AD commands to an Implicit Remoting Module – this is a module that lives on your local disk
    • PowerShell will create this in your Documents folder under WindowsPowerShell/Modules
  • 27. Step 3
    • To use the remote commands, make sure the remote machine is running
    • Import the module that ’s on your local computer
    • Notice that you specify a prefix for the remote commands
    • New-ADUser is now New-RemADUser
    • Helps distinguish remote commands
  • 28. Help?
    • You can ’t get help on remote commands until the remote session is running
    • Get the remote session running by trying to run a remote command
    • Break out of the command if you don ’t really want to run it
  • 29. Running Commands
    • What ’s on your local computer is a “pointer” to the real cmdlet running on the remote machine
    • The cmdlet execution takes place remotely; you see the results on your computer
    • Great way to run commands that don ’t, or can’t, exist on your local machine – but which do exist on another machine on the network
    • Great reason to get one Win2008R2 DC in the environment
  • 30. Finished?
    • The remote session will close as soon as your local PowerShell session closes
    • This all requires that PowerShell remoting be set up in advance – that ’s a whole separate session!
  • 31. Q&A
    • Last chance for Q&A
    • Also a last chance for some additional demos
  • 32. Thank You!
    • Please feel free to pick up a card if you ’d like copies of my session materials
    • I ’ll be happy to take any last questions while I pack up
    • Please complete and submit an evaluation form for this and every session you attend!
  • 33.  
  • 34. This slide deck was used in one of our many conference presentations. We hope you enjoy it, and invite you to use it within your own organization however you like. For more information on our company, including information on private classes and upcoming conference appearances, please visit our Web site, www.ConcentratedTech.com . For links to newly-posted decks, follow us on Twitter: @concentrateddon or @concentratdgreg This work is copyright ©Concentrated Technology, LLC