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.

Share/Bookmark

My Windows Server 2008 R2 Server Core has a very small footprint, it is a single processor/20gb hd/512mb ram machine. The first thing you need is the KMS Host key from your Microsoft Volume Licensing site or from your TAM.
The command to register the machine as the KMS host is slmgr /ipk <your key>

Once it is registered, you need to activate the host itself. Run slmgr -ato
You can check the status and brief description of the KMS host by running slmgr –dli

The verbose information is provided via slmgr –dlv

Once KMS is setup, it will register its SRV record in DNS. You can verify from your workstation if it has done so via,

nslookup -type=srv _vlmcs._tcp

From then on clients will automatically be reverted to your KMS host for activation but as hinted in the drawing above, starting with Windows 7 and 08 R2, the minimum threshold (activation attempts/requests) that are needed to fully activate the KMS host is 25 Vista/Windows 7 clients or 5 Server 2008 (R2). This number can comprise of virtual and physical loads, previously this was limited to physical systems only. The slmgr -dlv will show you the total requests received.
Note that the KMS is desgined to let you better manage your internal activation for compliance reason. Micrsoft does not go receive any internal information from between the KMS host and KMS client. KMS has you abide your EA Volume Licenseing, check the VL Product Groups shown in the diagram that are pertinent for your environment. I find the group B to be most commonly required.

Important note : Installing/configuring the KMS does not open up the pertinent firewall port (default port 1688). From running “slmgr -dli” you will notice that it says that the KMS is listening on port 1688 but the rule is not enabled so you may do so like this.

netsh advfirewall>FIREWALL add rule name=”KMS” dir=in action=allow protocol=tcp
localport=1688
Ok.

For more information see this link.

Share/Bookmark

Cache locking is a new security feature available with Windows Server® 2008 R2 that allows you to control whether or not information in the DNS cache can be overwritten. When a recursive DNS server responds to a query, it will cache the results obtained so that it can respond quickly if it receives another query requesting the same information. The period of time the DNS server will keep information in its cache is determined by the Time to Live (TTL) value for a resource record. Until the TTL period expires, information in the cache might be overwritten if updated information about that resource record is received. If an attacker successfully overwrites information in the cache, they might be able to redirect traffic on your network to a malicious site.

Cache locking is configured as a percent value. For example, if the cache locking value is set to 50, then the DNS server will not overwrite a cached entry for half of the duration of the TTL. By default, the cache locking percent value is 100. This means that cached entries will not be overwritten for the entire duration of the TTL. The cache locking value is stored in the CacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100.

You can configure the CacheLocking with DNSCMD utility from the command line (launched under elevated rights).

dnscmd /Config /CacheLockingPercent <percent>

You may also check the current percentage set for this setting with the /info switch of DNSCMD.

With above, the pertinent DWORD registry key is created under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters

However, in real world you push down this registry key via Group Policy Preferences to all your DNS servers. Values for the key are shown below.

Share/Bookmark

You can download the 44x24in poster from here

Share/Bookmark

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.

Share/Bookmark

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/

Share/Bookmark

The –passthru switch as chosen in the example shows the results.

Check out help for what you can do with this cmdlet such as when you need to add the computer account to a specific OU. Remember that adding machine via PowerShell to the domain does not require you to create the computer name before hand, but it pre-exists than its not an issue.

Few examples :

Add-Computer -domainname Domain02 -OUPath OU=testOU,DC=domain,DC=Domain,DC=com

Add-computer -workgroupname WORKGROUP-A

Add-computer -domainname Domain01; restart-computer   (this adds the restart option)

For more info. see http://technet.microsoft.com/en-us/library/dd347556.aspx

For reasons unknown to me the useful Rename-Computer cmdlet (shown in my earlier example) seems to have been removed past CTP3 builds and the RTM. Even though the technet reference for all Windows 7 PowerShell cmdlets still has it listed.

Here is a discussion I found.

http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/8cdf0302-a41d-4973-9bff-2923e7ad0178

Share/Bookmark

The Active Directory Management Gateway Service enables administrators to use the Active Directory module for Windows PowerShell and the Active Directory Administrative Center running on Windows Server 2008 R2 or Windows 7 to access or manage directory service instances that are running on Windows Server 2008 or Windows Server 2003 DCs.

“Note:    Installing the Active Directory Management Gateway Service on your Windows Server 2008–based or Windows Server 2003–based servers does not make it possible for you to install the Active Directory module or the Active Directory Administrative Center (which is available only on Windows Server 2008 R2 or Windows 7 operating systems) on these servers. “

For more info see http://www.shariqsheikh.com/blog/index.php/200907/what-is-active-directory-management-gateway-service-admgs/

Share/Bookmark

Ever wonder what controls the native permissions on the security principal such as Domain Admins and Administrators in Active Directory ? What if an owner changes the permission these entities have ? The permissions do come back. They must. John Policelli had a great article on the subject of AdminSDHolder and SDPROP in this month’s technet article. The magic is driven by the AdminSDHolder which is an object that resides under the System container of Domain NC. This object has a unique ACL which is used to control the permissions of security principals that are members of built-in AD groups, also known as “protected groups”. The SDPROP (Security Descriptor Propagator) is the process that runs in the background and complies all the permissions according to the AdminSDHolder.

Every hour, a background process called SDPROP runs on the domain controller that holds the PDC Emulator operations master role. It compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the ACL lists aren’t the same, the ACL on the security principal is overwritten with the ACL from the Admin–SDHolder object. In addition, inheritance is disabled on the security principal.

John has done an excellent job on explaining the process and how it can affect you. I would like to show you the one-liners with which you can look-up who is part of that “elite” bunch in your AD with PowerShell (ADWS) on Windows Server 2008 R2 and as well with PowerShell (and Quest) in Windows Server 2003 domain.

For every recipient of this process i.e security principal such as user, group or computer, there is an attribute named “admincount” that gets marked as “1″ indicating that this principal via nesting or explicitly is part of a protected group in AD.

On Windows Server 2008 R2 where can you use (ADWS), the simple command to retrieve the user and group objects with admincount set as 1 is this.

Get-ADgroup -LDAPFilter “(admincount=1)” | select name

Get-ADuser -LDAPFilter “(admincount=1)” | select name

In domains that are pre-Windows Server 2008 R2, you can use similar QAD cmdlets.

Get-QADGroup -LDAPFilter “(admincount=1)”

Get-QADuser -LDAPFilter “(admincount=1)”

If you would just like to get the total number of users, you may count it like this.

(Get-QADuser -Ldap “(admincount=1)”).count

Another great read on AdminCount, AdminSDHolder, and SDPROP is right here from Mike B. Smith.

Some discrepencies pointed out by Joe in the technet article. He explains in great detail. http://blog.joeware.net/2009/09/08/1693/

Share/Bookmark

There are now 6 different types of Domain Functional Levels;

1. Windows 2000 Mixed (supports NT4/2000/2003 DCs)
2. Windows 2000 Native (supports 2000/2003 DCs)
3. Windows Server 2003 Interim (supports NT4/2003 DCs)
4. Windows Server 2003 (supports only 2003 DCs)
5. Windows Server 2008 (supports only 2008 DCs)
6. Windows Server 2008 R2 (supports only 2008 R2 DCs)

And five forest functional levels:

1. Windows 2000 (supports NT4/2000/2003 DCs)
2. Windows 2003 Interim (supports NT4/2003 DCs)
3. Windows Server 2003 (supports only 2003 DCs)
4. Windows Server 2008 (supports only 2008 DCs)
5. Windows Server 2008 R2 (supports only 2008 R2 DCs)

See this for list of features for different Functional Levels.

Share/Bookmark