Active Directory Module for Windows PowerShell – Quick start guide

ADPowershell is available starting Windows Server 2008 R2. To play with AD Powershell cmdlets, you must have at least one Windows Server 2008 R2 domain controller (DC) in your domain.

Installing AD Powershell module:

On a Windows Server 2008 R2 box, open an elevated Powershell console window (powershell.exe) and run the following commands:

PS C:\> import-module servermanager
PS C:\> Add-WindowsFeature -Name "RSAT-AD-PowerShell" -IncludeAllSubFeature
NOTE: AD Powershell module is installed by default on a DC.

Loading AD Powershell module:

Open a Powershell console window and type

PS C:\> import-module activedirectoryActive Directory PSDrive:

If the machine is joined to a domain then a default drive named AD: is created. You can CD into this drive and use all the regular file system commands to navigate the directory. The paths are in X500 format.

PS C:\> cd AD:
PS AD:\>
PS AD:\> dir

PS AD:\> cd "DC=fabrikam,DC=com"
PS AD:\DC=fabrikam,DC=com> md "OU=myNewOU"

PS AD:\DC=fabrikam,DC=com> del "OU=myNewOU"
If you want to create a new drive connected to another domain/forest or use the more readable canonical path format, type:

PS C:\> New-PSDrive -PSProvider ActiveDirectory -Server "contoso.fabrikam.com" -Credential "Contoso\Administrator" -Root ""  -Name Contoso -FormatType Canonical

PS C:\> cd Contoso:
PS Contoso:\> dir | ft CanonicalName

PS Contoso:\> cd "contoso.fabrikam.com/"

Getting cmdlet list, help and examples:

Powershell uses verb-noun name-pair format to name cmdlets. For example:

New-ADGroup
Get-ADDomain
To get a list of AD cmdlets type

PS AD:\> get-help *-AD*
PS AD:\> get-help New-AD*        ## would list all the cmdlets that create new AD objects
To get more info on a specific cmdlet or read examples, type

PS AD:\> get-help set-aduser -detailed
PS AD:\> get-help get-aduser -examples
Tips: You can use the tab completion feature of Powershell to complete cmdlet names or parameter names. For example after entering the Verb- part of a cmdlet name you can hit <TAB> key to cycle through all of the nouns available for that verb.

Common tasks:

Here are some examples of commonly performed tasks using AD cmdlets:

PS C:\> New-ADUser –Name "John Smith" –SamAccountName JohnS –DisplayName "John Smith" –Title "Account Manager" –Enabled $true –ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "p@ssw0rd" -AsPlainText -force) -PassThru

PS C:\> New-ADGroup -Name "Account Managers" -SamAccountName AcctMgrs -GroupScope Global -GroupCategory Security -Description "Account Managers Group" –PassThru

PS C:\> New-ADOrganizationalUnit -Name AccountsDepartment -ProtectedFromAccidentalDeletion $true  -PassThru

PS C:\> Get-ADUser -Filter { name –like "john*" } ## Gets all the users whose name starts with John

PS C:\> Add-ADGroupMember -Identity AcctMgrs -Members JohnS

PS C:\> Get-ADGroupMember -Identity AcctMgrs

PS C:\> Get-ADPrincipalGroupMembership -Identity JohnS  ## Gets all the groups in which the specified account is a direct member.

PS C:\> Get-ADAccountAuthorizationGroup -Identity JohnS  ## Gets the token groups of an account

PS C:\> Unlock-ADAccount -Identity JohnS

PS C:\> Get-ADForest -Current LocalComputer

PS C:\> Get-ADDomain -Current LoggedOnUser

PS C:\> Get-ADDomainController -Filter { name -like "*" }  ## Gets all the DCs in the current domain

What next?

In the next post we will give an overview of Active Directory Powershell and talk about various cmdlets we provide in this release.

Enjoy!
Swami


Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

  • 27 Feb 2009 9:53 AM

    #

    Hello Swaminathan, thanks for opening this blog.

    Why you _require_ -Server parameter in New-PsDrive? You can provide default value for it pointing to current logon server for example. Same about -root parameter which can easily defaults to “” as in your example.

    Why not to make Canonical names default format btw? X500 requres quotes “every,time,when used,because, of, commas”, it right to left so hard to type, and tabcompletion works only on current level ( so you cant do cd mydomain.com\myou\[tab] for example).

    Anyway, thanks even for creating this option at all 🙂

    [PS <560> AD:\] Get-ADDomain

    Get-ADDomain : Parameter set cannot be resolved using the specified named parameters.

    Event if it cant be resolved (why not return my logon domain?) why not to ask me about required parameters, or return all matching objects, like Get-Process do for example?

    Same relates to all other your Get-* cmdlets.

    Get-ADUser -Filter { name –like “john*” } ## Gets all the users whose name starts with John

    Why not Get-ADSomething john* or even Get-ADSomething john ? You can use query by ANR (http://support.microsoft.com/kb/243299) as default parameter, and this will be perfect choice. Or another solution, just dont leave us with this ugly one. BTW, how to get _all_ users? 😉 Get-ADSomething (without params) should work. All other PowerShell cmdlets work this way, just look around.

    Is Get-ADAccountAuthorizationGroup is nothing other but Get-ADPrincipalGroupMembership with recurse parameter?

    Better to add Get-ADGroupMember and Get-ADPrincipalGroupMembership lacks -recurse parameter. This is high resurce consuming operation sometimes, but its very important and popular scenario.

    Why in one case you use “Principal” (Get-ADPrincipalGroupMembership) and in another “Account” (Get-ADAccountAuthorizationGroup)? As it seems to me – its equal meanings there. BTW, IMHO “ADObject” is better and more intuitive 😉

    Again…

    Get-ADDomainController -Filter { name -like “*” }  ## Gets all the DCs in the current domain

    Why not just Get-ADDomainController ? 🙂

    Thats all for today 🙂 I hope my silly critics somehow help you build the real PowerAD 😉 Thanks for your work.

    Vasily Gusev, MVP: Admin Frameworks.

  • 27 Feb 2009 10:56 AM

    #

    Almost forgotten… About Search-ADAccount… There is no such verb as Search- or Find- in PowerShell, and no need in it.

    There is quote from PowerShell concepts about verbs(http://msdn.microsoft.com/en-us/library/ms714428.aspx):

    Get

    Retrieves a resource. For example, the Get-Content cmdlet retrieves the content of a file. Pairs with Set.

    Do not use verbs such as Read, Open, Cat, Type, Dir, Obtain, Dump, Acquire, Examine, Find, or _Search_.

    All this functionality that it provides, must be built in the Get-AD* cmdlets.

    There is no good in building more and more cmdlets just for separate some aspects of same general task (exept if you get bonuses for it ;)). Get-ADObject (Account/Principal/Whatever) should Get any ad objects in any way that I want (I’m dont want to search, i want GET ;)). Get-ADUser/Computer is just special aliases for some popular types.

    Same with Set. Set-ADSomething should set any of Something properties, like password for example. Reset-ADPrincipalPassword doesnt hurt while it “alias” for Set-AdAccount -Password (Get-Credential).

    All this will make AD part of PowerShell better integrate in whole system.

    And… I’m dont noticed formatting of ad objects, just because I think it will be done some time later prior to release. Is it in plans? 🙂

    Vasily Gusev, MVP: Admin Frameworks.

  • 3 Mar 2009 1:57 AM

    #

    Thanks Vasily for the feedback. Here are some answers to specific questions.

    >> 1. Why you _require_ -Server parameter in New-PsDrive?

    -Server parameter is optional in all our cmdlets and by default the cmdlets talk to a suitable DC in the computer’s domain.

    >> 2. -root parameter which can easily defaults to “”

    Fair point.

    >> 3. Regarding – Why not Get-ADSomething john* or even Get-ADSomething john ? You can use query by ANR ..

    >> Get-ADDomainController -Filter { name -like “*” }  ## Gets all the DCs in the current domain

    >> Get-ADDomain : Parameter set cannot be resolved using the specified named parameters.

    We are working on the default behavior of all the cmdlets and the experience should be better in the next release 🙂

    The default parameter set for get directory object cmdlets such as: Get-ADObject, Get-ADUser, Get-ADGroup etc. is -Identity.

    The purpose of -Identity is to uniquely identify an object in a domain. Thus we only support identities (such as: distinguishedName, objectGuid, objectSid and samAccountName) that are guaranteed to be unique by the server. For certain special objects (example: Fine Grained Password policy, Site, Domain controller etc.) we support “name” as the identity.

    We will write more about Identity in a separate blog.

    Since, ANR can potentially return more than objects it does not qualify as Identity. However, you can run a ANR query using filter.

    PS C:\> get-aduser -Filter { anr -eq “John” }

    For getting all users type:

    PS C:\> get-aduser -Filter { name -like “*” }

    >> 4. Is Get-ADAccountAuthorizationGroup is nothing other but Get-ADPrincipalGroupMembership with recurse parameter?

    Not exactly. Get-ADAccountAuthorizationGroup returns all the security groups in which an account is a direct or indirect member. It does not include Distribution Groups.

    The returned set may also include additional groups that system would consider the user a member of for authorization purposes.

    >> 5. Why in one case you use “Principal” (Get-ADPrincipalGroupMembership) and in another “Account” (Get-ADAccountAuthorizationGroup)?

    Good question. We would like to address this in a separate blog. Watch out for a topic on “ADObject model”

    >> 6. About Search-ADAccount… There is no such verb as Search- or Find- in PowerShell, and no need in it.

    It is a valid verb in Powershell V2 (http://blogs.msdn.com/powershell/archive/2007/05/09/proposed-new-standard-verbs.aspx)

    >> 7. There is no good in building more and more cmdlets just for separate some aspects of same general task.

    Again a good question, but I would prefer to address this in a separate blog.

    For now here is a short answer:

    Get-ADUser/ADComputer are not just special aliases. They retrieve additional data and display them in rich format. They also accept data in rich format inside -Filter parameter.

    Similarly, Set-ADUser,Set-ADComputer, New-ADUser, New-ADGroup etc. provides additional/relevant parameters for creating/writing the respective objects.

    >> 8. And… I’m dont noticed formatting of ad objects, just because I think it will be done some time later prior to release. Is it in plans? 🙂

    Ah.. we thought no one would notice 🙂

    Once again thanks for the feedback. Keep them coming.

    Cheers,

    Swami

  • 3 Mar 2009 2:16 AM

    #

    Brandon Shell pointed out an elegant way to get a list of AD cmdlets. Here it is..

    PS C:\> get-command -module ActiveDirectory -verb get

    PS C:\> get-command -module ActiveDirectory -noun ADUser

    Cheers,

    Swami

  • 6 Mar 2009 1:09 AM

    #

    >The default parameter set for get directory object cmdlets such as: Get-ADObject, Get-ADUser, Get-ADGroup etc. is -Identity.

    >get-aduser -Filter { anr -eq “John” }

    You can have more than one default parameter (in different parameter sets), so it can easily be -Identity, and then (if input not valid X500 path) fallback to -Anr.

  • 6 Mar 2009 1:10 AM

    #

    > Ah.. we thought no one would notice 🙂

    You joking? 🙂 This is hard to beleive 🙂

  • 6 Mar 2009 5:41 PM

    #

    @Xaegr

    >> Ah.. we thought no one would notice 🙂

    > You joking? 🙂 This is hard to beleive 🙂

    Yes, I was just joking. Btw, was your comment regarding Provider cmdlet output? Or for all AD cmdlets?

    Cheers,

    Swami

  • 12 Mar 2009 1:23 AM

    #

    No, output from get-aduser is fine for me for example.

    Only one suggestion, please accept wildcard chars for -Properties parameter 🙂 Not all can remember ad property names form objects, so get-aduser someone -prop *logon* will be useful. And get-aduser someone -prop * of course.

  • 12 Mar 2009 10:32 PM

    #

    -Properties parameter does support * and returns all properties + ldap attributes set on the object.

    It does not support wildcard chars on the parameters. You can query the schema to get a list of all ldap attributes that can be set on an AD object.

    Here is a Powershell function that does this:

    function GetPossibleLdapAttributes() {

    Param ([Parameter(Mandatory=$true, Position=0)] [String] $ObjectClass)

    $rootDSE = Get-ADRootDSE

    $schemaObject = get-adobject  -filter { ldapdisplayname -like $ObjectClass } -Properties mayContain, SystemMayContain -searchbase  $rootDSE.SchemaNamingContext

    $schemaObject.MayContain

    $schemaObject.SystemMayContain

    }

    Type:

    PS C:\> GetPossibleLdapAttributes computer

    PS C:\> GetPossibleLdapAttributes user

    Cheers,

    Swami

  • 19 Apr 2009 12:31 PM

    #

    On cmdlets like new-aduser could we have -organizationalunit rather than -path  (an alias on the parameter would be acceptable).

    AD admins think in terms of OUs rather than paths plus it would be consistent with Exchange

  • PeterW
    8 Dec 2011 10:26 AM

    #

    ServerManager Best Practices for AD scan is showing two problems:

    1. ActiveDirectory-Powershell is not installed

    I’ve tried enabling it, but I’m told the feature isn’t recognized, even though dism /online /get-features lists it.

    2. Strict replication consistency should be enabled

    Not sure if I should do this considering the warning about lingering objects and possible forest-wide authentication issues if LOs exist and strict is enabled.

    How can I reinstall the ActiveDirectory-Powershell feature and enable it?

    Should I worry about the strict setting?

    Help!

Query in CMD for FSMO Roles

Question

1

Sign in to vote

Hello,

Is there some command in DOS or PowerShell to quickly determine where are FSMO roles in AD?

Thank you.

Monday, September 10, 2012 5:33 AM

Reply | Quote |

ChristianGomez19805 Points

Answers

2

Sign in to vote

Hi Christian!

Try this:

netdom query fsmo

Regards!

Pablo Ariel Di Loreto

IT Consultant

This posting is provided “AS IS” with no warranties and confers no rights! Always test ANY suggestion in a test environment before implementing!

Marked as answer by ChristianGomez1980 Monday, September 10, 2012 5:41 AM

Monday, September 10, 2012 5:37 AM

Reply | Quote |

Pablo Ariel Di LoretoAlgeiba IT (Partner) 4,340 Points

1

Sign in to vote

Christian!

Netdom is a command-line tool that you can use from CMD (and will work from PowerShell too).

Please see: http://technet.microsoft.com/en-us/library/cc835089(v=ws.10).aspx

Regards!

Pablo Ariel Di Loreto

IT Consultant

This posting is provided “AS IS” with no warranties and confers no rights! Always test ANY suggestion in a test environment before implementing!

Marked as answer by ChristianGomez1980 Monday, September 10, 2012 5:52 AM

Monday, September 10, 2012 5:48 AM

Reply | Quote |

Pablo Ariel Di LoretoAlgeiba IT (Partner) 4,340 Points

1

Sign in to vote

You can simply open cmd and execute the command netdom query fsmo this will list the FSMO role holder server.You can also check the same from GUI or ntdsutil.See below link how to check the same.

http://www.petri.co.il/determining_fsmo_role_holders.htm

FSMO Roles and PowerShell

FSMO Roles and PowerShell

Best Regards,

Sandesh Dubey.

MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

Disclaimer: This posting is provided “AS IS” with no warranties or guarantees , and confers no rights.

via Query in CMD for FSMO Roles.

2 Free Microsoft Windows Server 2012 Antivirus Solutions.

2 Free Microsoft Windows Server 2012 Antivirus Solutions.

November 16th, 2013 by Andrea Matesi 1562 Views 

 

By default, Windows Server 2012 comes without a security solution.

This is especially important if you use 2012 as a robust workstation OS for your studying needs.

So, to protect your time-consuming lab-rat experiments, you might feel left “high and dry“.

‘Though not everything is lost, since there are 2 hacks you might wish to implement to provide a minimum form of protection to your lab.

 

1. Microsoft Security Essentials for Windows 7 into Windows Server 2012.

The first hack allows you to install Microsoft Security Essentials (MSE).

Microsoft Security Essentials is designed for Windows 7 and is not compatible (nor supported) on Windows Server 2012.

But if you insist, you might as well end-up installing it on your Windows Server 2012.

  1. Download a copy of MSE from Microsoft: http://windows.microsoft.com/en-us/windows/security-essentials-all-versions
  2. Right Click on the “mseinstall.exe”.
  3. Click on Properties.
  4. Click on the “Compatibility”-tab.
  5. Locate the “Compatibility mode”-section.
  6. Check “Run this program in compatibility mode for:”.
  7. Select From the (now active) dropdown menu “Windows 7″.
  8. Open a Command Prompt as Administrator.
  9. cd to your Downloads folder (ie. cd C:\Users\%username%\Downloads).
  10. Run “mseinstall /disableoslimit” and follow the installer prompts to install MSE on your Windows Server 2012.

 

2. Microsoft Endpoint Protection 2012 (part of the System Center 2012 suite).

Microsoft Endpoint Protection 2012 is part of a freaking awesome Microsoft System Center suite.

For further info, please refer to http://en.wikipedia.org/wiki/System_Center#Microsoft_System_Center

They are all fully integrated & automated Client/Server solutions that satisfy specific system administration requirements (in addition to the already excellent features provided by Windows Server).

Among those, there’s Microsoft Endpoint Protection 2012, which is a Client/Server Security solution that fully integrates with your Active Directory Domain.

In layman’s words, Microsoft Endpoint Protection 2012 could be considered as the “full” version of Microsoft Security Essentials (aka Windows Defender on Windows 8/8.1).

The solution includes both a “Server” application (ie. to deploy on your application server) and a “Client” counterpart (ie. for your workstations).

  • The hack here is the possibility to run the Client as a “standalone” product (ie. without the Server application).

Not only, you can get the client “for free”, by simply downloading the Trial version of the entire Microsoft Endpoint Protection 2012 suite (trial refers to the Server Application).

To install System Center 2012 Endpoint Protection on Windows Server 2012 proceed as follows:

  • Download Microsoft System Center Configuration Manager and Enpoint Protection 2012 SP1 from the following address:

http://technet.microsoft.com/en-US/evalcenter/hh667640.aspx?wt.mc_id=TEC_105_1_33

Once you obtain the package (mine was named SC2012_SP1_RTM_SCCM_SCEP.exe and it was 613MB):

  1. Right Click on it and open the archive with 7zip.
  2. Extract the “CLIENT”-Folder from SC2012_SP1_RTM_SCCM_SCEP.exe into a temporary location.
  3. Browse to the CLIENT folder with Windows Explorer and run “SCEPINSTALL.exe”.
  4. Follow the installer Prompts and you’ll end up with a fully featured  Security Solution courtesy of Microsoft.

System Center 2012 Endpoint Protection System Center 2012 Endpoint Protection System Center 2012 Endpoint Protection System Center 2012 Endpoint Protection

 

 

Personal remarks.

Now, apart from what’s moral and what’s not, Microsoft highly likely wishes you to “give it a go” (at their own Security solutions).

Despite glorious bugs that made glowing news during the previous decade, Microsoft takes a serious stand when it comes to Security.

How?! For one, by constantly releasing Windows “Security Updates”.

Pair that with a basic form of malware protection and you might just end up covering 80% of your security needs.

Independent testing says:”meh..!“.

If you asked me what’s my favourite professional security suite, I’d say:”it depends“.

If you’re an SMB with limited resources (and perhaps close to none IT personnel), then I’d lean towards a fully managed OOB solution (like Bitdefender).

If you’re a Windows-only Enterprise or Government organization, then I’d lean towards a secured Active Directory domain environment (ie. w/Applocker & IPSec), with the integration & automation provided by Microsoft System Center-based solutions (such as Endpoint Protection 2012).

Thoughts welcome.