Import-module ActiveDirectory

You see a progress bar with a message like following:

Basically, during the import-module phase, the AD provider tries to mount a new drive with the name ‘AD’ targeting a Domain Controller (DC). It locates the DC by using the DsGetDcName APIs implemented by the Netlogon service. More information about DC location can be found here.

Upon finding a DC which satisfies certain conditions like the availability of the web service etc, the AD provider tries to mount a new drive targeting that DC. Let’s say that the name of the DC found is MyClosestDC.domain.com, then mounting the drive is similar to typing the following command:

New-PSDrive –Name “AD” –Root “” –PsProvider ActiveDirectory –server “MyClosestDC.domain.com”

Do note that the AD Provider targets the DC in the current machine’s domain. If a DC is not found, as in the case of a machine which is not domain joined, then the default drive is not created and a warning is displayed.

Disable the loading of the default drive

If for some reason, you want to disable the loading of the default drive, then all you have to do is set the value of the environment variable ‘ADPS_LoadDefaultDrive’ to ‘0’. In powershell, this can be achieved by typing the following command:

PS Env:\> $Env:ADPS_LoadDefaultDrive = 0

Now when you import the AD module, the default drive will not be loaded.

This is particularly useful when you are trying to invoke an ADPowershell cmdlet through a command line or vb/powershell script and do not want to load the drive. For example following can be run in a cmd window:

C:\Windows\System32> Powershell.exe –Command $Env:ADPS_LoadDefaultDrive=0; Import-Module ActiveDirectory; Get-ADUser muali -server MyDC;

Please note the above powershell commands only effect the current user session. For a permanent change in the environment variables, use SETX as following:

PS C:\> SETX ADPS_LoadDefaultDrive 0 /M

Cheers,

Ali

---

Mudassir Ali

Software Development Engineer in Test – Active Directory Powershell Team

function Get-XADUserPasswordExpirationDate() {

    Param ([Parameter(Mandatory=$true,  Position=0,  ValueFromPipeline=$true, HelpMessage="Identity of the Account")]

    [Object] $accountIdentity)

    PROCESS {

        $accountObj = Get-ADUser $accountIdentity -properties PasswordExpired, PasswordNeverExpires, PasswordLastSet

        if ($accountObj.PasswordExpired) {

            echo ("Password of account: " + $accountObj.Name + " already expired!")

        } else { 

            if ($accountObj.PasswordNeverExpires) {

                echo ("Password of account: " + $accountObj.Name + " is set to never expires!")

            } else {

                $passwordSetDate = $accountObj.PasswordLastSet

                if ($passwordSetDate -eq $null) {

                    echo ("Password of account: " + $accountObj.Name + " has never been set!")

                }  else {

                    $maxPasswordAgeTimeSpan = $null

                    $dfl = (get-addomain).DomainMode

                    if ($dfl -ge 3) { 

                        ## Greater than Windows2008 domain functional level

                        $accountFGPP = Get-ADUserResultantPasswordPolicy $accountObj

                        if ($accountFGPP -ne $null) {

                            $maxPasswordAgeTimeSpan = $accountFGPP.MaxPasswordAge

                        } else {

                            $maxPasswordAgeTimeSpan = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge

                        }

                    } else {

                        $maxPasswordAgeTimeSpan = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge

                    }

                    if ($maxPasswordAgeTimeSpan -eq $null -or $maxPasswordAgeTimeSpan.TotalMilliseconds -eq 0) {

                        echo ("MaxPasswordAge is not set for the domain or is set to zero!")

                    } else {

                        echo ("Password of account: " + $accountObj.Name + " expires on: " + ($passwordSetDate + $maxPasswordAgeTimeSpan))

                    }

                }

            }

        }

    }

}

Here are some sample usages of this function:

PS AD:\> Get-XADUserPasswordExpirationDate testuser1
Password of account: testuser1 already expired!

PS AD:\> Get-XADUserPasswordExpirationDate JohnDoe
Password of account: John Doe expires on: 02/25/2010 13:03:20

Since the MSDN article explains the algorithm using a flow diagram, I too have tried creating a flow diagram that explains the logic used to compute the password expiration date of an account:

Hope you find this useful. Please leave a comment if you have any feedback on this topic or would like to see any other topic discussed in our blog.

Enjoy,

Swami

· Add-ADGroupMember

· Remove-ADGroupMember

· Add-ADPrincipalGroupMembership

· Remove-ADPrincipalGroupMembership

Example:

C:\PS> Add-ADGroupMember SvcAccPSOGroup -Member SQL01, SQL02   ## Adds the user accounts with SamAccountNames SQL01,SQL02 to the group SvcAccPSOGroup.

C:\PS> Remove-ADPrincipalGroupMembership -Identity "Wilson Pais" -MemberOf "Administrators" ## Remove the user 'Wilson Pais' from the administrators group.

However, when it comes to adding and removing cross-forest or cross-domain members from a group, things become a little difficult. Here is an example of the error message that you would see while trying to do cross-forest/domain operations the regular way:

The issue here is that Add-ADGroupMember cmdlet tries to resolve the identity supplied in its -MemberOf parameter first and then update the group membership. Since the identity supplied in –MemberOf parameter is from ForestBBB the cmdlet fails while trying to resolve the identity against ForestAAA and throws an identity not found exception (ADIdentityNotFoundException).

The correct way to update cross-forest/domain membership is to first fetch the cross-forest/domain object using any of the ADPowershell cmdlets and then supply the fetched object as input to –Members or –MemberOf parameter of the cmdlets.

Example:

If you want to use Add-ADPrincipalGroupMembership cmdlet then first fetch the group object and save it in a variable and then execute Add-ADPrincipalGroupMembership cmdlet targeting ForestBBB.

Here are the commands that are executed in the screenshots above.

PS ForestAAA:\> $forestBBBUser = Get-ADUser swami -Server $forestBBB
PS ForestAAA:\> Add-ADGroupMember Administrators -Members $forestBBBUser
PS ForestAAA:\>
PS ForestAAA:\> $forestAAAGroup = Get-ADGroup Administrators
PS ForestAAA:\> Add-ADPrincipalGroupMembership -Server $forestBBB swami -MemberOf $forestAAAGroup
PS ForestAAA:\> Remove-ADPrincipalGroupMembership -Server $forestBBB swami -MemberOf $forestAAAGroup

Remove members from group
Do you want to remove all the specified member(s) from the specified group(s)?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS ForestAAA:\>
PS ForestAAA:\>

The reason why the above commands work is that ADPowershell cmdlets stores session information in the objects returned.

      The variable $forestBBBUser in the above example contains “server = $forestBBB” in its session information, which is stored internally and is not visible/accessible via command line.

This session information is used by Add-ADGroupMember (and other membership cmdlets) to resolve the identity and add it to the group in $forestAAA.

NOTE: In the above examples I have connected to the forest where the group resides.

Hope this post helps you in managing your group membership via ADPowershell.

Cheers,

Swami

--

Swaminathan Pattabiraman

Developer – Active Directory Powershell Team

By now you might know that you can use Get-ADDomain cmdlet for viewing the well-known containers of a domain, For example:

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Get-ADDomain | select *Container


ComputersContainer                 : CN=Computers,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
DeletedObjectsContainer            : CN=Deleted Objects,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
DomainControllersContainer         : OU=Domain Controllers,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
ForeignSecurityPrincipalsContainer : CN=ForeignSecurityPrincipals,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
LostAndFoundContainer              : CN=LostAndFound,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
QuotasContainer                    : CN=NTDS Quotas,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
SystemsContainer                   : CN=System,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
UsersContainer                     : OU=SwamTempOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com

However, Get-ADDomain cmdlet does not show you all the well-known containers. For example some lesser known containers such as: Program Data Container, Managed Service Account Container (which is technically an Other-Well-Known container) etc. are missing. Also, one cannot change/redirect a well-known container to some other OU using Set-ADDomain cmdlets.

These limitations can be easily overcome using Get-ADObject and Set-ADObject cmdlets. This blog discusses how to do these tasks using ADObject cmdlets and also provides easy-to-use functions for them.

Fetching well-known containers is really simple. All you have to do is read the wellKnownObjects and otherWellKnownObjects properties of the domain’s default naming context.

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Get-ADObject (Get-ADRootDSE).DefaultNamingContext -Properties otherWellKnownObjects, wellKnownObjects | fl OtherWellKnownObjects, wellKnownObjects


OtherWellKnownObjects : {B:32:1EB93889E40C45DF9F0C64D23BBB6237:OU=TestMSAOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com}
wellKnownObjects      : {B:32:A9D1CA15768811D1ADED00C04FD8D5CD:OU=SwamTempOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com, B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com, B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Program Data,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com, B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data, DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com...}

These properties contain a list of well-known object containers by GUID and distinguished name. Of course you must know the GUID of the container that you are looking for, to find its value.

Also, changing/redirecting a well-known container can be done using Set-ADObject cmdlet by removing the old value from wellKnownObjects/otherWellKnownObjects attribute on the default naming context (i.e. DC=domainname,DC=com) and adding a new value. For example in order to redirect the Users container, one would run the following command:

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Set-ADObject (Get-ADRootDSE).DefaultNamingContext -Remove @{wellKnownObjects = "B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com" } -Add @{wellKnownObjects = "B:32:A9D1CA15768811D1ADED00C04FD8D5CD:OU=SwamTempOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com" } -server (Get-ADDomain).PDCEmulator

NOTE: The operation must be performed on the Primary domain controller (PDC).

Though it is feasible to use Get-ADObject and Set-ADObject cmdlets to read and manipulate well known containers, it is cumbersome. I have written few functions that would Get and Set the values of these containers.

In order to express the container name in a user-friendly way (rather than a cryptic GUID) I have created a new Enum called: WellKnownGuid. (I used a modified version of Add-Enum script described here in order to create the Enum)

There are two functions Get-XADWellKnownContainer and Set-XADWellKnownContainer that would get and set the value of a well-known container identified by its WellKnownGuid.

Example:

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Get-XADWellKnownContainer UsersContainer
OU=SwamTempOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com


PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Get-XADWellKnownContainer ComputersContainer
CN=Computers,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com

For getting the values of all the Well-known containers of a domain type this:

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> [Enum]::GetNames([WellKnownGuid]) | %{ $_.PadRight(30) + " : "+(Get-XADWellKnownContainer $_)}
UsersContainer                 : OU=SwamTempOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
ComputersContainer             : CN=Computers,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
SystemsContainer               : CN=System,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
DCContainer                    : OU=Domain Controllers,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
InfrastructureContainer        : CN=Infrastructure,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
DeletedObjectsContainer        : CN=Deleted Objects,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
LostAndFoundContainer          : CN=LostAndFound,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
ForeignSecurityPrincipalContainer : CN=ForeignSecurityPrincipals,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
ProgramDataContainer           : CN=Program Data,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
MicrosoftProgramDataContainer  : CN=Microsoft,CN=Program Data,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
NtdsQuotasContainer            : CN=NTDS Quotas,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com
ManagedServiceAccountContainer : OU=LeakTestOU,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com

For changing/redirecting a well-known container simply pass the container name and new DN to Set-XADWellKnownContainer function.

Example:

PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Set-XADWellKnownContainer  UsersContainer CN=Users,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com"


PS C:\Users\Administrator.DSWAMIPAT-W7-V1> Get-XADWellKnownContainer  UsersContainer
CN=Users,DC=dswamipat-w7-vm1,DC=nttest,DC=microsoft,DC=com

The script that contains these functions can be found attached to this blog.

For more information on well-known containers, read this: Binding to Well-Known Objects using WKGUID.

Cheers,

Swami

RedirectingWellKnownGuidContainer.ps1

Constructed Replication XML Metadata Attribute	Available on Objects	Corresponding Binary Attribute
msDS-ReplQueueStatistics	Root DSE	-
msDS-ReplAllInboundNeighbors	Root DSE	-
msDS-ReplAllOutboundNeighbors	Root DSE	-
msDS-NCReplCursors	NC Head	replUpToDateVector
msDS-NCReplInboundNeighbors	NC Head	repsFrom
msDS-NCReplOutboundNeighbors	NC Head	repsTo
msDS-ReplAttributeMetaData	All Objects	replPropertyMetaData
msDS-ReplValueMetaData	All Objects	-

For the Inspecting Deleted Objects before Restore blog post script, I had parsed the msDS-ReplAttributeMetaData attribute of the deleted objects to determine the actual deleted time of the objects. I had found the parsing so simple to do using ADPowerShell, that I decided to write about it in this separate post.

This post is focused on the msDS-ReplAttributeMetaData attribute … but the technique shown here can be used to parse all of the above listed XML format attributes …

Let’s start by a simple Get-ADObject call and requesting the msDS-ReplAttributeMetaData attribute.

Get-ADObject "DC=DUGILL,DC=DEMO" -Properties "msDS-ReplAttributeMetaData"

Let’s store the xml string value in a local variable so that we can play with it without cluttering the commandline. Now, the attribute name has a hyphen (‘-’) in it so we will need to help the powershell parser and put quotes around the attribute name.

$xmlAttribute = (Get-ADObject "DC=DUGILL,DC=DEMO" -Properties "msDS-ReplAttributeMetaData")."msDS-ReplAttributeMetaData"

Above we see that the xml text from the attribute is not a valid xml string, as it does not have a root tag. So let’s add a root tag to it.

$xmlAttribute = “<root>” + $xmlAttribute + “</root>”

Now that we’ve made our msDS-ReplAttributeMetaData attribute value a valid xml string, comes the turn of some PowerShell magic. PowerShell makes it really simple to convert XML string to an XML Document Object (a form which can be worked on programmatically in a simpler way …)

SO, let’s go ahead and cast the string into an XML Document object.

$xmlAttributeDocObject = [xml] $xmlAttribute # wow … it’s that simple

Ok not that simple … we hit a pretty nasty looking parsing error. The error is because the XML string contains some ASCII null characters (a bug in AD). So how do we get rid of these null charecters?

The hint is in the error which says the char has a hex value of 0x00 which is basically decimal 0. Can I use String.Replace function to get rid of these characters? As it turns out – I can …

String.Replace takes two arguments: first, the char or string to replace and second, the char or string to replace with. Note I’m using PowerShell casting again, to convert the hex value 0x00 to a char value. Replacing all occurrences of ascii nulls in the string with a space char (“ ”) …

$xmlAttribute = $xmlAttribute.Replace([char]0,” ”)

Now let’s try converting it into the XML Doc Object again … this time it works!!

$xmlAttributeDocObject = [XML]$xmlAttribute

Let’s inspect the xml doc object and admire the wonderful XML experience provided by PowerShell :)

And finally $xmlAttributeDocObject.root.DS_REPL_ATTR_META_DATA | ft #… viola!

BTW, this output had got me wondering if I had just typed repadmin /showmeta …

Focusing on selected interesting XML elements …

$xmlAttributeDocObject.root.DS_REPL_ATTR_META_DATA | ft pszAttributeName,ftimeLastOriginatingChange,pszLastOriginatingDsaDN

We see that the originating change time is in the Zulu time format and the originating dc’ NTDS Settings object DN is what is available … with some format transforms we can get to a better looking output

$ObjectMetadataTableFormatter = @()

$ObjectMetadataTableFormatter += @{Label="Attribute LDAP Name"; Expression={$_.pszAttributeName}}

$ObjectMetadataTableFormatter += @{Label="Originating DC"; Expression={(Get-ADObject $_.pszLastOriginatingDsaDN.Substring(17,$_.pszLastOriginatingDsaDN.length-17) -properties dnshostname).DNSHostName}}

$ObjectMetadataTableFormatter += @{Label="Originating Change Time"; Expression={[datetime]::parse($_.ftimeLastOriginatingChange)}}

$xmlAttributeDocObject.root.DS_REPL_ATTR_META_DATA | ft $ObjectMetadataTableFormatter

You may also use the attached script function (or add it into your function profile script). The function allows pipelining objects from other Get-AD cmdlets to fetch the object replication metadata …

enjoy!

Dushyant Gill

Program Manager - Microsoft

ReplicationMetadata.ps1

## Get the object’s DACL

PS AD:\> $acl = get-acl "OU=myou,DC=fabrikam,DC=com”

## Finding out if an ACL is protected is very simple.

PS AD:\> $acl.AreAccessRulesProtected

## When setting ACL to be protected with SetAccessRuleProtection with the first parameter set to $true, we also 

## have two options for the ACEs already inherited, we may choose either to remove them or convert them to 

## explicit ACEs. In the example below, we choose to convert the inherited ACEs by setting the second parameter 

## to $true.  

PS AD:\> $acl.SetAccessRuleProtection($true, $true);

## Make sure set the ACL on the object after the change has been made to the ACL.

PS AD:\> set-acl -aclobject $acl "OU=myou,DC=fabrikam,DC=com”

## Once the ACL is protected the inheritance chain is broken

## To unprotect the ACL (i.e. to fix the broken inheritance), set the first parameter to $false. The second parameter is ignored in the case.

PS AD:\> $acl.SetAccessRuleProtection($false, $false);

## Always make sure set the ACL on the object after any change has been made to the ACL

PS AD:\> set-acl -aclobject $acl "OU=myou,DC=fabrikam,DC=com”

Thanks,

David

One of the unique aspects in access control management in Active Directory is the introduction of object specific ACEs which allow an administrator to delegate Active Directory specific rights (i.e. extended rights) or read/write access to a property set (i.e. a named collection of attributes) by setting ObjectType field in an object specific ACE to the rightsGuid of the extended right or property set. The delegation can also be created to target child objects of a specific class by setting the InheritedObjectType field to the schemaIDGuid of the class. For more information on how to retrieve the rightsGuid or schemaIDGuid using Active Directory Powershell, please refer to Swami’s blog How to find extended rights that apply to a schema class. In the example below, we are going to create two object specific ACEs with one granting the group “myGroup” the extended right “Reset Password” for all users and the other giving it permission to delete computer objects, all under the organizationUnit “myOU”.

## Load Active Directory Powershell Module

PS C:\> cd ad:

PS AD:\> 

## Create myOU

PS AD:\> $ou = new-adorganizationalunit -name myOU -passthru

## Create myGroup and obtain its SID 

PS AD:\> $group = new-adgroup myGroup -groupscope global -passthru

PS AD:\> $sid = new-object System.Security.Principal.SecurityIdentifier $group.SID

## Get the DACL of myOU

PS AD:\> $acl = get-acl $ou

## The following object specific ACE is to grant myGroup permission to create computer objects under myOU.

## Note that bf967a86-0de6-11d0-a285-00aa003049e2 is the schemaIDGuid for the computer class.

PS AD:\> $objectguid = new-object Guid bf967a86-0de6-11d0-a285-00aa003049e2                          

PS AD:\> $ace1 = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid,"CreateChild","Allow",$objectguid

## The following object specific ACE is to grant myGroup permission to change user password on all user objects 

## under myOU. 00299570-246d-11d0-a768-00aa006e0529 is the rightsGuid for the extended right 

## User-Force-Change-Password (“Reset Password”). bf967aba-0de6-11d0-a285-00aa003049e2 is the schemaIDGuid 

## for the user class. 

PS AD:\> $objectguid = new-object Guid  00299570-246d-11d0-a768-00aa006e0529

PS AD:\> $inheritedobjectguid = new-object Guid  bf967aba-0de6-11d0-a285-00aa003049e2

$ace2 = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid,"ExtendedRight",$objectGuid,"Descendents",$inheritedobjectguid

## Add the ACE in the ACL and set the ACL on the object 

PS AD:\> $acl.AddAccessRule($ace1)

PS AD:\> $acl.AddAccessRule($ace2)

PS AD:\> set-acl -aclobject $acl $ou

Thanks,

David

1) Stop Active Directory Web services by typing “net stop adws” on a command prompt.

2) Save a copy of the original %systemroot%\windows\adws\Microsoft.ActiveDirectory.WebServices.exe.config file.

3) Now open the file %systemroot%\windows\adws\Microsoft.ActiveDirectory.WebServices.exe.config for editing.

4) Copy and paste the following lines after </appSettings> tag in the file above:

   <system.diagnostics>
      <sources>
        <source name="System.ServiceModel.MessageLogging">
          <listeners>
                   <add name="messages"
                   type="System.Diagnostics.XmlWriterTraceListener"
                   initializeData="c:\messages.svclog" />   <!-- Provide your desired path for log file here -->   
          </listeners>
       </source>
     </sources>
  </system.diagnostics> 

And the following lines just under <system.serviceModel> tag:

   <diagnostics>
     <messageLogging 
          logEntireMessage="true" 
          logMalformedMessages="true"
          logMessagesAtServiceLevel="true" 
          logMessagesAtTransportLevel="true"/>
    </diagnostics>

5)  Save and close the config file.

6)  Start the service using “net start adws” and make sure configuration file got loaded successfully by checking the ADWS event log ID 1100  “The configuration file for Active Directory Web Services has been loaded without errors.”

7) Open Active Directory Module for Windows Powershell and run any AD cmdlet.

8) Note that a file called c:\message.svclog got created which contains all the XML messages!

Message.svclog contains a sequence of XML fragments and is not a valid XML file. It is recommended that you use the Service Trace Viewer Tool (SvcTraceViewer.exe) to view the message log files in a more formatted manner. For more information on how to use this tool, see Using Service Trace Viewer for Viewing Correlated Traces and Troubleshooting.

For e.g. below is a Get-Transfer root dse request from AD powershell to ADWS:

And the Get-transfer response to the above request from ADWS:

This mechanism of logging messages comes very handy while debugging errors and exceptions. It is also useful to see the exact message sent to/from the ADWS in raw form, for ex: by looking at the request XML sent by Get-ADObject one can find out how Advanced Filters are converted to ldap filters. By setting appropriate message logging options it is possible to view malformed messages and faults. One can also view XML messages communication between Active Directory Administrative Center and ADWS through such logging. 

Enjoy!

Swasti Mishra

Developer – Active Directory Web Services team

There are KB articles that describe how to find extended rights that apply to a given objectClass using VBScript or C++.

https://support.microsoft.com/kb/302514

I was curious to find out how easy or difficult it is to do this in AD Powershell. It turned out to be pretty straightforward, just a few lines of code. Compare this with the ~81 lines of VB Script code in the above KB article.

Here is the script in AD Powershell:

$inputObjectClass = "group"

$rootDSE = Get-ADRootDSE
$configNCDN = $rootDSE.ConfigurationNamingContext
$schemaNCDN = $rootDSE.SchemaNamingContext
$extendedRightsDN = "CN=Extended-Rights," + $configNCDN
$classObject = get-adobject -SearchBase $schemaNCDN -Filter { name -eq $inputObjectClass -and objectClass -eq "classSchema"} -Properties SchemaIDGUID
if ($classObject -ne $null) {

    $schemaIDGuid = [System.Guid] $classObject.SchemaIDGUID
    Get-ADObject -SearchBase $extendedRightsDN -Filter { appliesTo -eq $schemaIDGuid  } -Properties RightsGuid,cn,displayname | Select RightsGuid,cn,displayname

} else {

    Write-Error ("Specified class object not found! : " + $inputObjectClass)

}

Although SchemaIDGuid is stored as a Octet String (i.e. Byte[]), look how easy it is to convert that into a System.Guid object. Just a simple type-cast in Powershell does that.

    $schemaIDGuid = [System.Guid] $classObject.SchemaIDGUID

Cheers,

Swami

• Windows Server® 2003 R2 with Service Pack 2 (SP2)
• Windows Server 2003 SP2
• Windows Server 2008
• Windows Server 2008 SP2

ADMGS enables administrators to use Windows Server 2008 R2 or Windows 7 client applications such as the Active Directory module for Windows PowerShell and the Active Directory Administrative Center (ADAC) to access or manage their existing Active Directory Domain Services (ADDS) and Active Directory Lightweight Directory Services (AD LDS) instances that are running on Windows Server 2008-based (both writable and read-only) or Windows Server 2003-based servers.

The only difference between the functionality that ADWS provides for domain controllers that are running Windows Server 2008 R2 operating system and the functionality that ADMGS provides to domain controllers that are running Windows Server 2008 and Windows Server 2008 SP2 operating systems is that ADMGS does not support instances of the Active Directory Database Mounting Tool running on Windows Server 2008-based servers.

Downloadable install guide at the same location provides information on ADMGS installation, uninstallation and upgrade scenarios.

Enjoy!

Swasti Mishra

Developer -  Active Directory Web Services team