Auditing Group Membership changes


I often get this asked this question, “how do I audit group membership changes”. Whereas a lot of AD Change Monitor Tools (Quest, Netwrix etc.) have nice reports that can be generated to look up this information, this question comes up when a change auditor product for AD is not in picture. Let me cover the highlights here.

1. You need to have the Auditing enabled with Group Policy.

Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesAudit Policy



2. In order to see on which DC the change was made, you can lookup the metadata via repadmin.

repadmin /showobjmeta test-dc01 "CN=Test Group,OU=Groups,DC=techevan,DC=lab"

Towards the end of the output you see the “absent” in this example on which DC a particular user was removed from this group.

Type     Attribute     Last Mod Time         Originating DSA         Loc.USN          Org.USN Ver        Distinguished Name
===  ========  ===========      =================   ======= ======= === =========================
ABSENT   member        2010-11-05 16:55:28 TestSiteTEST-DC01  749327  749327   2  CN=Rick Sheikh,OU=Users,DC=techevan,DC=lab


3.  You can comb the logs on the said DC using EventComb or Event Viewer. Event ID 4729 is logged when a member is removed from a group.


Some other important Event IDs for User and Group Auditing in Windows Server 2008 R2 are these:

4727 – A security-enabled global group was created.

4728 – A member was added to a security-enabled global group.

4730 – A security-enabled global group was deleted.

4731 – A security-enabled local group was created.

4732 – A member was added to a security-enabled local group.

4733 – A member was removed from a security-enabled local group.

4734 – A security-enabled local group was deleted.

4735 – A security-enabled local group was changed.

4737 – A security-enabled global group was changed.

4754 – A security-enabled universal group was created.

4755 – A security-enabled universal group was changed.

4756 – A member was added to a security-enabled universal group.

4757 – A member was removed from a security-enabled universal group.

4758 – A security-enabled universal group was deleted.


More reading here :

Server Core R2 DC promotion fails due to unavailable ADDS binaries


I encountered an issue promoting a Server Core R2 to a domain controller. The DCPROMO on Server Core is handled via unattended mode with answer file. The error I received is below. It was due to Server Core’s inability to install/confirm ADDS binaries.

C:UsersAdministrator>dcpromo /unattended:answer.txt
Checking if Active Directory Domain Services binaries are installed…
Failed to detect if Active Directory Domain Services binaries were installed. The error was: An error with no description has occurred.

And the DCPROMOUI.log also shed some light on the nature of the issue.

dcpromoui 504.204 001E 03:01:08.709     Unable to find identity string for package name Microsoft-Windows-ServerCore-Package
dcpromoui 504.204 001F 03:01:08.709   Failed to retrieve the parent package name
dcpromoui 504.204 0020 03:01:08.709   HRESULT = 0x800F0818
dcpromoui 504.204 0021 03:01:08.709   HRESULT = 0x800F0818
dcpromoui 504.31C 0022 03:01:08.709     HRESULT = 0x800F0818
dcpromoui 504.31C 0023 03:01:08.709   Enter GetErrorMessage 800F0818

My attempt to add the binaries via the DISM also failed.

dism /online /enable-feature /featurename:DirectoryServices-DomainController-ServerFoundation

Deployment Image Servicing and Management tool
Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Error: 0x800f0818

DISM failed. No operation was performed.
For more information, review the log file.

The DISM log file can be found at C:WindowsLogsDISMdism.log  

The OCSETUP attempt also failed sighting the same error.

ocsetup DirectoryServices-Domain-Controller-ServerFoundation




After I had ensured that the OS was up-to-date with patches and updates, I stumbled upon System Update Readiness Tool KB947821. What is System Update Readiness Tool ? it is a patch that helps you find the inconsistencies with system files.

System resources, such as file data, registry data, and even in-memory data, can develop inconsistencies during the lifetime of the operating system. These inconsistencies might be caused by various hardware failures or might be caused by software issues. In some cases, these inconsistencies can affect the Windows servicing store, and they can cause software updates not to work. The System Update Readiness Tool tries to resolve these inconsistencies.

The System Update Readiness Tool creates a log file that captures any issues that the tool found or fixed. The log file is located at the following location:

  • %SYSTEMROOT%LogsCBSCheckSUR.persist.log

On this Server Core, the CheckSUR.log indicated issues with two files (its an update specific MUM file with its catalog file), that the tool found to be corrupted.

Checking System Update Readiness.
Binary Version 6.1.7600.20822
Package Version 10.0
2011-02-19 20:53

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs
(f)    CBS MUM Corrupt    0x00000000    servicingPackagesPackage_for_KB2207566_RTM~31bf3856ad364e35~amd64~~        Expected file name Microsoft-Windows-ServerCore-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Seconds executed: 165
Found 1 errors
  CBS MUM Corrupt Total count: 1

Unavailable repair files:

I also came across this Technet forum post, which is similar in nature but is applicable to different corrupt files with different symptoms, however it was this post that gave me the idea to fix my problem.

Solution :

1. I downloaded the KB2207566 (Windows6.1-KB2207566-x64.msu) as indicated by SUR log, and copied it to Server Core (c:temp). Note that this patch already had been installed but for some reason had the mentioned files corrupted.

2. I then extracted the MSU file into a sub folder and extracted the *.cab files.

C:UsersAdministrator>cd c:temp

c:temp>wusa Windows6.1-KB2207566-x64.msu /extract:c:servicingkb2207566

c:temp>cd kb2207566

c:tempkb982214>mkdir files

c:tempkb982214>expand -F:* files

The two files I had to replace were these :


The location for the existing files that had to be replaced was c:windowsservicingpackages and an issue I ran into, as it was indicated on the Technet post (when I simply attempted to UNC and copy from another regular W2K8 machine) was that these were protected files and the copy/create option was denied. Lot of systems folders/files in Windows 7 and Windows Server 2008 have a different owner than ‘administrators’ and the TrustedInstaller is set as owner and has full control rights set.


3. And I then opted to use the command line option to take the ownership of the folder and assign ‘administrators’ the full rights on the Server Core.

takeown /f c:windowsservicingpackages /r /d y

icacls c:windowsservicingpackages /grant administrators:F /T

4. And lastly I copied the extracted files and replaced.

C:tempkb982214files>copy "package_for_kb2207566_rtm~31bf3856ad364e35~amd64~~6" c:WindowsservicingPackages

Overwrite c:WindowsservicingPackagespackage_for_kb2207566_rtm~31bf3856ad364e (Yes/No/All): y

1 file(s) copied.

C:tempkb982214files>copy "package_for_kb2207566_rtm~31bf3856ad364e35~amd64~~6
.1.1.0.mum" c:WindowsservicingPackages

Overwrite c:WindowsservicingPackagespackage_for_kb2207566_rtm~31bf3856ad364e
35~amd64~~ (Yes/No/All): y

1 file(s) copied.

No restart was required and the DCPROMO with the answer file succeeded as it was now able to install the ADDS binaries and the DC promoted successfully.

Note that prior to the fix I also noticed that I was unable to enable the remote management from the SCONFIG (option 4, sub option 3) which also worked afterwards.

Exchange 2010 Setup and .Net Framework 3.5 SP1 Requirement


Starting with Exchange 2007, the good thing about the setup wizard is that it guides you about all the pre-requisites and provides the links from where you can download them from.


However, if you are installing Exchange 2010 on Windows Server 2008 (or R2) box, and if you follow the link provided by the wizard and download the general .Net Framework 3.5 from MS Downloads you are likely to get the error “You must use the Role Management Tool to install or configure Microsoft .Net Framework 3.5” upon installing it.


As the .Net Framework 3.5 is bundled in as a “feature” and you must add it from the Server Manager/Features snap-in (formerly add/remove programs). This should not be only pertinent to Exchange but would be applicable to all other apps that require .Net Framework 3.5)


PowerShell : How do I check Active Directory Tombstone Lifetime ?


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


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


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.

Can I install KMS on Server Core ?


Server Core seems to be the perfect candidate for installing KMS. Key Management Service mediates your Volume Licensing with Microsoft Activation Services and acts as the man-in-the-middle for the activation for all your KMS clients that comprise of Vista, Windows 7, Windows Server 2008 and R2. With Windows 7 and Windows Server 2008 R2, what you have in KMS is Volume Activation 2.0. In contrast with KMS, what you have is MAK that stands for multiple activation key. MAK is targeted for clients that stay off the network whereas KMS is designed for your internal clients. Following I have a simple overview design of how it works.


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

For more information see this link.

PowerShell : How do I find old Trusts ?


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.


Get-QADUser -SearchRoot ‘’ -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}

PowerShell : Set-ADAccountPassword cmdlet in Windows Server 2008 R2


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.

Another look at Active Directory Administrative Center (ADAC)


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

Also watch this short webcast by Kevin Remde