Shariq Sheikh | Port 389

For small shops that do not leverage automated provisioning tools, they face challenge in keeping the attributes for Users and other objects in AD standardized. For similar situation, recently I was asked from Access Control team if there is an easy way to fix the displayName attribute for all users or to fill in the display name where its missing based on the Users’ first and last name. The answer is a simple PowerShell one-liner using Quest Cmdlets.

Using Get-QADUser cmdlet, you can define the location of all your users using the –searchlevel parameter or you can sweep the whole directory for all user accounts. And then pipe the results to the foreach and use Set-QADuser to fix the display names (in this example) based on the users’ first and last name

Get-QADUser mydomain.int/users -sl 0 | foreach {Set-QADUser $_ -DisplayName ("{0} {1}" -f $_.firstname,$_.lastname)}

The –sl 0 parameter defines the limit of users to 0.

What is Active Directory Tombstone Lifetime (TSL) ?

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

Directory Services veteran and MVP Joe Richards has published a short blog entry demystifying the confusion a technet article has caused in regards to how to go about figuring a TSL on a particular domain. Note that new forests that are installed with Windows Server 2003 with SP1 and up have a default tombstone lifetime of 180 days.

Joe shares his ADFIND tool to lookup the current value of the TSL attribute (irrespective of what OS was used to build the forest). Note that as Joe pointed out if this attribute is not set (i.e empty value) then the TSL is 60 days. Here I show you how to lookup the TSL with PowerShell.

Using Quest cmdlets :

Get-QADbject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=int” includeallproperties | Select TombstoneLifetime

And with using native AD cmdlets (of ADWS) in Windows Server 2008 R2 :

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -properties tombstonelifetime

Also within PowerShell, you can also use ADSI to lookup the TSL value.

[ADSI]$config=LDAP://cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,DC=R2,dc=lab

$config.TombstoneLifetime

Also, here is how you can use DSQUERY from the Windows Support Tools to lookup the TSL.

dsquery * “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -scope base –attr

tombstonelifetime

Note that I have used my test forest’s DN of R2.lab in above examples, be sure to replace the values with your forest’s DN. Above query should be typed in one line.

As usual a good conversation spurred on ActiveDir on a much discussed scenario of virtualizing your DCs while be varied of the known pitfalls. While virtualized DCs are fully supported on either competing virtualization solution by Microsoft, one known subject I would like to highlight here is the proper time synchronization. You must make sure that your PDCe gets its time from an external time source and other DCs follow the PDCe. All DCs (including PDCe) must not sync their time with the virtualization host, whether its VMware ESX or that of Hyper-V. It was discussed how by default the VMware’s VM settting does not have the time synchronization enabled by default, and my brief look at the Hyper-V’s VM suggested that it is. In any case, you must make sure that setting is disabled, thus VM does sync its time with its host.

VMware time setting from the VMware tools within the VM:

Or under the VM settings from VIC :

Hyper-V setting from the VM settings :

A great resource to refer to, to learn how to configure an authoritative time source for your DCs – see this KB http://support.microsoft.com/kb/816042

As usual Joe shared a great insight that trusts well-doing can in one way be verified by checking the trust accounts for their last password resets. When trusts are created the accounts for them are by default created under ‘Users’ container, and are named as TrustedDomain$ and just like computer accounts, trusts reset their password every 30 days, and . He showed how to look up the ‘pwdlastset’ attribute using his ADFIND tool. Below I show you the PowerShell way.

$old=(get-date).adddays(-30)

Get-QADUser -SearchRoot ‘mydomain.int/users’ -Name “*$*” -IncludedProperties pwdlastset | where {$_.pwdlastset –gt $old}

You may also sort and view the results as below

Any trusts that have not reset their passwords in last 30 days are probably no longer valid. If you are using ADWS on Windows Server 2008 R2, then something like below should suffice, assuming you have already created the $old variable using the same command as above.

Get-ADUser -Filter ‘Name -like “*$*”‘ -Properties pwdlastset | where {$_.pwdlastset –gt $old}

Here is quick snippet of password set/reset ‘Set-ADaccountPassword’ cmdlet in 08 R2 via ADWS (native AD cmdlets) and a test screencast from me.

I highly recommend to use the built in cmdlet help to learn the syntax and available parameters. Whether you are using the cmdlet as an one-off task or trying to incorporate it into a script.

First we run, Help Set-ADaccountPassword -examples to look at what the options are and then use,

Set-ADaccountPassword -Identity Moyo -reset where the user id is moyo, and provide the new value of the password. Unlike many other functions where you must run the ADWS under elevated ‘administrative’ privileges, if you are running this cmdlet on your DC, you can run this under normal security context.

Previously I had briefly written about ADAC and today we take a look at some of the things you can accomplish by this new interface of Active Directory.

We start out by launching the ADAC, by running DSAC.exe from the run window

ADAC offers two views, the list view

and the tree view

There are several useful queries built-in which you can add from the ‘Add criteria’ button such as find all the users with expired passwords

And add multiple criteria to your query

From the task pane, you can create a new user

Its an ease of use to be able to fill in all the pertinent attributes from a single interface

Now you can raise DFL and FFL from one location, previously you had to raise the FFL from AD Domains and Trusts snap-in

From the Global Search page, you can simply also add your own LDAP query

You can add specific navigation nodes into your list-view such as the Users container and apply different filters (query) to do a comparison side-by-side, from the same ‘add navigation nodes’ window you can also add other trusted domains to manage multi-domain environment all in one place.

For more info. see http://technet.microsoft.com/en-us/library/dd560651(WS.10).aspx

Also watch this short webcast by Kevin Remde http://edge.technet.com/Media/Exploring-the-Active-Directory-Administrative-Center-SRV311-Part-1-of-5/

The Active Directory Groups Nesting restrictions is an often-discussed topic among my peers especially in a multi-domain forest and often a question raised in forums and mailing lists. Although there have been some great blogs written that dive deep into the technical restrictions, I personally needed a simple reference chart that I could refer to and which serves me as a memory refresher. Between the two types of Active Directory Groups, Security and Distributions, there are restrictions in both but this attempted reference chart covers only Security type. There are three scopes of Security Groups. Domain Local, Global, and Universal. A leading practice for each of these scopes for NTFS permissions is as follows. Domain Local Groups are used for permissions (ACLs), Users are populated in Global Groups, and Universal Groups are used to manage Global Groups. But often times there are needs to circumvent this model and cross nesting is required especially in a multi-domain forest or in a large environment with multiple forests. The nesting restrictions of each group that you must know about can be broken into three questions and subsequent charts below :

Please note that these nesting restrictions assume Window 2000 native or Windows Server 2003 DFL.

1. Which particular group will take other scope type (nested) as its member i.e from the same domain and from a trusted domain ?

Chart 1 for Question # 1

Chart 2 for Question # 1

2. Where can a particular group be assigned permissions (ACL) i.e only in the domain where it resides and also cross domains ? (trusted or other child domains within the same forest )

All three scope types can be used to assign permissions in the same domain where the groups reside.

Chart 1 for Question # 2

3. Which group will accept users and computers from same and trusted domain ?

All three scope types will accept Users and Workstation from the same domain where they reside.

Chart 1 for Question # 3

More information on the scope of these groups can be found here:

http://technet.microsoft.com/en-us/library/cc755692.aspx

To learn about a leading access control model known as AGDLP see :

http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1255549,00.html

A question was raised on ActiveDir, and I learned about an old TechNet Jigsaw on AD’s interworking.

Along with that, there was a new Windows Server 2008 AD Feature Components which I received at Tech-Ed 2007 and it illustrates the new and improved AD pieces introduced with Windows Server 2008. This poster covers ADLDS, ADFS, ADRMS, and RODCs.

And an additional poster on general new Windows Server 2008 Feature Components that covers TS, NAP, IIS 7.0, Virtualization, Server Core and BitLocker.

Both of the above illustrations and very good quality large size posters (30×20in) and are good to hang in your office/cube. Printing them on regular printer may distort the quality, so you may try the plotter . All three can be downloaded from the following links :

TechNet Magazine Active Directory Component Jigsaw Poster

Windows Server 2008 Component Posters (both)

P.S This is my first test post using WLW.

I have created an Active Directory Custom Search Engine (using Google CSE). It searches for the relevant content based on the sites I have added. The point is to remove all the unnecessary hits you get from using the regular Google search and make sure you get hits from the most smart AD bloggers. I have also added a few PoSH blogs from folks who often write on the “AD management” with PowerShell. So far the engine only searches in the 35 sites I have added, I will be certainly adding more so feel free to leave a comment with your suggestion. Click here to get to it.

So next time you have an AD related query, just type it up in this search engine and you are likely to find what you are looking for. The searched site list is of the prestigious AD bloggers and writers (MVPs,ActiveDir and EE) whom its very likely to find a discussed topic from to your AD query. Personally, it serves me as a tool I could go back to when I remember that I had read about something particular on someone’s blog but can’t remember whose site it was.

Here is the list of searched sites and it will likely be growing.

http://blogs.dirteam.com/blogs/tomek/

http://blogs.dirteam.com/blogs/carlos/

http://blogs.technet.com/activedirectoryua/

http://blogs.dirteam.com/blogs/acefekay/

http://blogs.dirteam.com/blogs/paulbergson/

http://msmvps.com/blogs/UlfBSimonWeidner/

http://blogs.dirteam.com/blogs/sanderberkouwer/

http://blog.joeware.net

http://www.briandesmond.com/blog

http://www.bsonposh.com

http://blogs.msdn.com/adpowershell/

http://blogs.technet.com/heyscriptingguy/

http://jdhitsolutions.com/blog/

http://blogs.microsoft.co.il/blogs/ScriptFanatic/

http://blogs.msdn.com/powershell/

http://poshoholic.com/

http://jacksonshaw.blogspot.com/

http://tigermatt.wordpress.com/

http://www.highorbit.co.uk/

http://www.frickelsoft.net/blog/

http://dmitrysotnikov.wordpress.com/

http://adisfun.blogspot.com/

http://www.open-a-socket.com/

http://www.shutuplaura.com/

http://www.joekaplan.net/

http://www.sdmsoftware.com/blog/

http://imav8n.wordpress.com/

http://blogs.technet.com/josebda/

http://blogs.technet.com/askds/

http://blogs.microsoft.co.il/blogs/guyt/

http://www.gilkirkpatrick.com/Blog/

http://blogs.technet.com/grouppolicy/

http://blogs.dirteam.com/blogs/jorge/

http://blogs.technet.com/instan/default.aspx

http://blogs.technet.com/ad/default.aspx

Thanks to Mike Kline for sharing a couple of links.

Update :
Following links were shared by weemat

blogs.technet.com/filecab
blogs.technet.com/networking
blogs.technet.com/askperf
blogs.msdn.com/w32time

Much has been said about the manageability of AD Recycle Bin in Windows Server 2008 R2 via the Microsoft’s intended way i.e via PoSH cmdlets. Though this option stays to be only enable-able via PowerShell, the ability to restore objects (the process of reanimation of objects in earlier ADs) has been extended to GUI by Overall Solutions Inc. The GUI tool is very simple to use and its available for free. Below I show you how to restore a deleted OU with objects inside via this tool. See previous post on how to enable the AD Recycle Bin feature in your Windows Server 2008 R2 forest.

We delete an OU called Chicago which contains a Global Group.

Launch the ADRecycleBin tool (be sure to launch it under administrator’s context)

Right click on the child object of a deleted tree and select all

Click on Restore Deleted Object on top right corner

And its simple as that. Lesson of the story, there is always a window for someone to step in and fill the void. I had earlier posted how Server Core that was intended to be managed via CLI only had made a  U-TURN in R2 release of Windows Server 2008. Personally, I wouldn’t mind having to manage this feature solely from PowerShell, but its nice to have the GUI option available.

Download the tool here.

Launch the PowerShell under Administrator’s account context, and type this cmdlet.

Enable-ADOptionalFeature -Identity ‘CN=Recylcle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com

Read and understand the warning of this action’s irreversebility, and hit “Y” for yes to continue.

In following screenshot I show you an error not neccesarily applicable to you, the cmdlet complained about not being able to verify the FSMO ownership role. The reason for this was the fact that in my VM Lab environment I had shut down another DC for maintenance and it had not been replicated or talked to.

As I brought that downed DC back online, forced the replication, I was able to proceed. You can then confirm with this cmdlet.

Get-ADOptionalFeature ‘Recycle Bin Feature’

Here is a great post on this hot feaure of Windows Server 2008 R2.

http://msmvps.com/blogs/ad/archive/2009/03/31/taking-out-the-trash.aspx

As briefly discussed before, a feature to offline domain join machines is available in Windows Server 2008 R2. The utility is called “djoin.exe” which is used to perform this task. Here is an official blurb on what the offline domain join is what it would be used for and then I will show you how to perform this simple task.

“Offline domain join is a new process that computers that run Windows® 7 or Windows Server® 2008 R2 can use to join a domain without contacting a domain controller. This makes it possible to join computers to a domain in locations where there is no connectivity to a corporate network. For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time required for wide-scale virtual machine deployments.

A domain join establishes a trust relationship between a computer running a Windows operating system and an Active Directory® domain. This operation requires state changes to Active Directory Domain Services (AD DS) and state changes on the computer that is joining the domain. To complete a domain join in the past using previous Windows® operating systems, the computer that joined the domain had to be running and it had to have network connectivity to contact a domain controller”

I created the metadata as known as “blob” on one of my DC for a Server named 2008R2RC2 that I wanted to join to domain offline (i.e the target machine not connected to the network) and saved it to a txt file called computer_prov, then as usual I run the help on the utility to learn what syntax it has available. Here is the command syntax I ran to provision the computer account and to create the metadata.

djoin /provision /domain techevan.lab /machine 2008R2RC2 /savefile c:computer_prov.txt

I then jumped on the target machine, copy the txt file over and try to run needed syntax with the djoin utility

djoin /requestODJ /loadfile c:computer_prov.txt /windowspath %SystemRoot% /localos

I get an error that I am not running the Shell with elevated privileges, I get out and get back in with the “run as administrator” option, and get the same error.

Perhaps its a bug in RC release, I then tried the same syntax from the conventional CMD line window and was successful.

I then restarted the target computer and machine had been joined to the domain.

For more information please see, http://technet.microsoft.com/en-us/library/dd392267(WS.10).aspx

A couple years back someone made a recommendation on Microsoft Exchange Forums that equivalent to Exchange BPA, it would be nice for AD Admins to have an AD Best Practices Analyzer, this was passed on to the AD Team. Though I am not if this particular thread was the driver behind it, but starting in Windows Server 2008 R2, AD Admin will have the BPA.

“Active Directory Domain Services (AD DS) Best Practices Analyzer (BPA) is a server management tool that can help you implement best practices in the configuration of your Active Directory environment. AD DS BPA scans the AD DS server role as it is installed on your Windows Server 2008 R2 domain controllers, and it reports best practice violations. You can filter or exclude results from AD DS BPA reports that you do not need to see. You can also perform AD DS BPA tasks by using either the Server Manager graphical user interface (GUI) or cmdlets in the Windows PowerShell command-line interface.”

ADBPA is a great idea, it gives you a quick glance into the new DC you have just stood up. It points you toward setting the NTP settings correctly if the DC is also PDC. It lets you know if your OUs are not set to be protected from accidental deletion. It also reminds you that certain directory partitions (NC) have not been backed up since a certain of period time. You can access the ADBPA from the Server Manager -> ADDS.

You may notice that if you are running the Windows Server 2008 Beta version, there seems to be a bug with ADBPA rule. One of the non-compliant complain is about the DC’s inability to reach a DNS server to retrieve DC specific records even when the DC itself is also the DNS and the pertaining records are existing. This behavior has been corrected in the RC version.

The compliant section also shows where your DC meets the expected configuration, such as when it advertises itself as a DC in its local site. One downside I see with ADBPA is that it cannot be self-launched into its separate MMC. Or unlike the Exchange BPA, it is only accessible in a small window from within the Server Manager. So there if is large number of non-compliant/compliant messages, the browsing ability is not that great.

How does ADBPA gather this data ?

“When you run the AD DS BPA scan on a domain controller, the BPA engine invokes the AD DS BPA Windows PowerShell script that collects configuration data from the AD DS environment that this domain controller belongs to. The AD DS BPA Windows PowerShell script then saves the collected AD DS configuration data to an XML document. The BPA run-time engine validates this XML document against the XML schema.”

For more information on ADBPA. See this.

It is version 47 in RC and it may very well change when R2 gets RTM. You can check the objectVersion attribute of your current forest on the Schema Naming Context (NC) via ADSIedit.msc.

Here are some older Schema versions.

13=Win2k
30=2003
31=2003R2
44=2008

Here is more detail of schema changes in Windows Server 2008 R2 RC.

http://technet.microsoft.com/en-us/library/dd378828(WS.10).aspx

Who needs ADRAP or ADHC when you have this in front of you. This is a modification of “Good code, Bad code” by the author credited on the picture.

Have no more than 1200 DCs in your domain..say new scalability limits.

I wonder if anyone realistically has reached that limit without a need to break down the domain into multiple domains/forest, this limitation lies in FRS’s ability to keep things sane with the SYSVOL replication. The new Active Directory Maximum Limits – Scalability recently published has very interesting pieces of information. I am highlighting below some key bullet points.

• Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.

• There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain.

• Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups.

• Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.).

• The maximum length for the name of an organizational unit (OU) is 64 characters.

• There is a limit of 999 GPOs that you can apply to a user account or computer account.

• The recommended maximum number of members in a group is 5,000. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.(Thanks to LVR).

• For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200.

Even though this technet-published-content puts Windows Server 2008 in context as identified in the applies to section, unfortunately details do not dive into direct scalability improvements for native Windows Server 2008 and R2 Forests. All in all even with a Windows Server 2003 forest, the limitation mentioned here are rarely to be hit in a production environment.

Lets you know if the account’s status on current DC (you are connected thru ADUC) is locked/unlocked. I did a post earlier regarding account lockouts in Windows Server 2003. This small feature is good to have.

I will tell you that  ‘if’ but first off, for those not aware, meet ADAC, the successor for your ADUC.

Active Directory Administrative Center, an idea long awaited for by AD Admins. Starting in Windows Server 2008 R2 and RSAT tools in Windows 7, you will have a richer administrative console for your Active Directory that will replace the good old ADUC (Active Directory Users & Computers). This is perhaps the first revamped console to manage AD since the very inception of Active Directory in year 2000.

Built on Windows PowerShell™ command-line interface technology, Active Directory Administrative Center provides network administrators with an enhanced Active Directory data management experience and a rich graphical user interface (GUI). Administrators can use Active Directory Administrative Center to perform common Active Directory object management tasks through both data-driven navigation and task-oriented navigation

Yet there is a catch before you take advantage of this powerful tool in your current production environment. You need to have atleast one Windows Server 2008 R2 running DC in your domain. This is a little downside for the early adopters of the technology who would like to take advantage of the extended tool in their current production environment. And without the required scenario as mentioned here, you are likely to see the error as shown below.

Among other things you can do with ADAC, here is a couple of features:

• Connect to one or several domains or domain controllers in the same instance of Active Directory Administrative Center, and view or manage the directory information for those domains or domain controllers
• Filter Active Directory data by using query-building search

Some greats blogs have been written on this subject, take a look :

http://policelli.com/blog/?p=305
http://wss-id.org/blogs/bobby/archive/2009/03/24/windows-server-2008-r2-active-directory-administrative-center-first-look.aspx
http://blogs.technet.com/activedirectoryua/archive/2009/01/30/introducing-active-directory-administrative-center.aspx

We are all aware how helpful the repadmin tool has become (available thru Windows Support Tools in Windows Server 2003 and earlier) for troubleshooting the replication issues. In Windows Server 2008, this tool along with others come pre-packaged within the OS. You no longer have to install the Support Tools to rein in the benefits of handy command line tools such as, dcdiag, netdiag, rendom and many others.

Here is one repadmin syntax I have become used to as it gives me a snapshot of source DCs and the Destination DCs and their replication status. The command is repadmin /replsum

In above scenario there are two DCs (both Windows Server 2008) showing their latest largest delta times. The Source DC is one that changes have gone out from, where as Destination DC is one who adopted changes from other DC, hence replicated.

What needs to be noticed here is under normal circumstances both DCs would show up under Source and Destination, but since the VM08-02 is a read-only domain controller it can only grab changes from other DC and can’t replicate changes out from it. It only shows up under Destination DC and shows that it was at the receiving end of applying changes to it in terms of Active Directory replication. While read-write domain controller (RWDC) shows changes replicated out from it i.e VM08-01.

The fail/total %% and error column comes very handy when somewhere out there one of your DC has stopped talking to others or hasn’t been talked to due to an issues such is incorrect firewall settings.

Repadmin is one handy tool that all AD Admins should invest a little time learning. For more information on repadmin /showrepl command, click here.

Sounds like a no-brainer, but there is catch. I installed DHCP role on my Server Core that I had previously set up as Read-only Domain Controller, using this command.

start /w ocsetup DHCPServerCore

And then I went ahead and set the service configuration to “auto” with this command,

sc config dhcpserver start= auto (note the space between the equal sign and auto)

And then finally when I tried to start the DHCP service with the following command, it failed with these errors.

net start dhcpserver

A system error has occured

System error 50 has occured

The request is not supported

So the catch was, that since RODC can’t write back to the AD to create the needed DHCP security groups i.e DHCP Administrators and DHCP Users, the service would fail.

After creating those domain local security groups on another Windows Server 2008 RWDC, the service does run successfully and you can manage the DHCP Server (that is running on Server Core) from another server using RSAT.

The Windows Server 2008 Server Core installation does support Read Only Domain Controllers (RODC). This support makes Server Core ideal for brance office scenarios. To make a Server Core part of your domain as RODC, you use the unattended answer file with the following text with your settings and passwords

[DCInstall]
InstallDNS=Yes
ConfirmGC=Yes
RebootOnCompletion=Yes
ReplicaDomainDNSName=2008.lab
ReplicaOrNewDomain=readonlyreplica
ReplicationSourceDC=dc3.2008.lab
SafeModeAdminPassword=
SiteName=Default-First-Site-name
UserDomain=2008.lab
UserName=admin08
Password=
CreateDNSDelegation=No

You can place the text file on the root of your C drive on the server core and run the following command

dcpromo /unattend:unattend.txt where unattend.txt is the text file you created above

Later on we will discuss other embedded command line structures and built-in programs such as OCSETUP which will allow you to add roles and features to your server core. Keep in mind that making the domain controller is the only setup you must not use OCSETUP for, and you must utilize DCPROMO for it, otherwise your server may not function properly.

After running the above process, you will notice that from a Windows Server 2008 full installation, using ADUC we can readily confirm that our DC is RODC.

In a previous post we discussed the FSMO Roles and we know that one of the FSMO Roles is RID Master. What a RID Master does and whats its significant, let’s recap. RID Master – Each object must have a globally unique number (GUID). The RID master makes sure each domain controller issues unique numbers when you create objects such as users or computers. For example DC one is given RIDs 1-4999 and DC two is given RIDs 5000 – 9999.

In this post I will be showing you the command which you can run to check the available Relative Identifiers (RID) pool on one of your DCs.

You should have the Windows Server 2003 Support tools installed and the command to run is as follows:

dcdiag /v /test:ridmanager

/v is for verboselogging and the /test:ridmanager is to define the specific test and to avoid the other dcdiag test runs. Take a look at the attached screenshot above, It shows the current RID Allocation Pool and the Previous Allocation Pool. 500 RIDs are assigned from the RID Master and after 50% of the pool has been consumped, another request for pool refill is made to the RID Master.

Every domain has a default setting for ms-DS-MachineAccountQuota value 10. This means that any user can add up to 10 machines to a domain. You can modify this object in directory by using ADSIedit tool to prevent this behavior.

Warning: Using ADSIedit can have adverse effects on your Active Directoy environment, if not handled with proper knowledge.

Launch ADSIedit from run command, ADSIedit.msc

Under Domain Configuration, expand and find your domain. Right click and go to the Properties

Look for the following property and modify it to ‘0′

Hit OK, Apply and exit

How does it keep track of how many machines have you added based on your user ID/account ?

For a computer account created by domain users, the account has ‘ms-DS-CreatorSID’ attribute to indicate the creator user. When a user adds a computer to the domain, a process enumerates the ‘ms-DS-CreatorSID’ attribute on every computer account in the domain and calculates if the sum exceeds the current quota for that user.

The ‘ms-DS-CreatorSID’ and ‘ms-DS-MachineAccountQuota’ with default value 10 are also available in Windows Server 2008 AD DS.

Note: The ‘ms-DS-CreatorSID’ attribute will be unset in the computer account that is pre-created in Active Directory Users and Computers MMC or joined by domain administrators.

http://support.microsoft.com/kb/243327

Where Account Lockouts save us from brute force password attacks and help us standardize our environment for password policies, sometimes it can be painful to troubleshoot and find out why and where it happened. Microsoft does provide us with the ‘Account Lockout Management Tools’ suite which can be very handy to diagnose the root cause of an account lockout.

· AcctInfo.dll. Helps isolate and troubleshoot account lockouts and to change a user’s password on a domain controller in that user’s site. It works by adding new property pages to user objects in the Active Directory Users and Computers Microsoft Management Console (MMC).

· ALockout.dll. On the client computer, helps determine a process or application that is sending wrong credentials.

· ALoInfo.exe. Displays all user account names and the age of their passwords.

· EnableKerbLog.vbs. Used as a startup script, allows Kerberos to log on to all your clients that run Windows 2000 and later.

· EventCombMT.exe. Gathers specific events from event logs of several different machines to one central location.

· LockoutStatus.exe. Determines all the domain controllers that are involved in a lockout of a user in order to assist in gathering the logs. LockoutStatus.exe uses the NLParse.exe tool to parse Netlogon logs for specific Netlogon return status codes. It directs the output to a comma-separated value (.csv) file that you can sort further, if needed. The latest version available is 1.0.0.60.

· NLParse.exe. Used to extract and display desired entries from the Netlogon log files.

Unfortunately, I didn’t find good documentation of how to quickly make good use of these tools when my domain admin account started getting mysteriously locked out after I had changed my password due to the policy in place. From my experience I found Lockout Status and EventComb MT to be most useful from the suite.

I knew the common causes why my account would get locked out due to one of the reasons listed here : See this but I needed to figure out what is the offending machine or service thats providing my old credentials to a DC thats causing the account to be locked out.

I started out launching Lockout Status tool and selected my domain admin account as ‘target’ from the file menu and running it. It gave me list of all the DCs with the status of my account and more importantly the DC the lockout happened on in the ‘Orig Lock’ tab towards the right of the program screen. I then launched the Event CombMT piece and right clicked in the white space in the search area and added the DC the lockout originated at. I choose from ‘Option’ menu where I wanted to output the file as txt or CSV. I chose ‘Security’ as log files search option for all event types and then putting ‘644′ as the event id and clicked on search.

It outputted the CSV file in the area I had specified and I was able to see that it found the event 644 for my ID on 6 different machines across the domain, it was listed under ‘Caller Machines Name’ column, (I know its bad administration on my part to sometimes disconnect my terminal sessions instead of logging off). Sure enough when I logged on to those machines I immediately saw the following notifications.

I had to log off and log back in to clear out the error. After that, I ran the Lockout Status tool again and noticed the lock status for my domain admin account had been cleared out.

Conclusion: Never leave your account logged on somewhere (or have a service run under your user context) and lock the machines or disconnect the remote session without logging off, and when using tools like Remote Desktops (which can be useful and allow you to have a list of machines you remote in frequently during the day), make sure you don’t save your passwords in the session configurations.

More Resources:

Download the Microsoft Account Management Tools

Technet Resource on how to maintain and manage the account lockout

WindowsSecuirty.com-Implementing and Troubleshooting Account lockout

Maybe the most forgotten password is the one for Directory Services Restore Mode (DSRM) because it’s created only when a DC is built, and used only during critical DC recovery operations, which hopefully does not happen very often. Not knowing this password can prevent a successful recovery.

If you don’t know your DSRM password and haven’t stored them in a safe place, use the following commands for each Domain Controller to reset it to a known value:

ntdsutil
set dsrm password
reset password on server {servername}

Once you do this, write down that password and lock/encrypt it away.