Zoho Banner September 2011

Archive for July, 2014

When you install a new version of Exchange or apply a Cumulative Update certain AD attributes are updated to reflect the change.  The updates are made in three different directory partitions (also known as naming contexts): Schema, Configuration and Domain.  The following Microsoft TechNet article is a good reference for the different versions and the corresponding attribute values.


You can check the values manually….or you could do it the easy way with Powershell.  Here’s a Powershell sample to give you values across the three partitions (assumes a single domain forest):


# Exchange Schema Version
$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
(Get-ADObject $ob -pr rangeUpper).rangeUpper

# Exchange Object Version (forest)
$cc = (Get-ADRootDSE).ConfigurationNamingContext
$fl = "(objectClass=msExchOrganizationContainer)"
(Get-ADObject -LDAPFilter $fl -SearchBase $cc -pr objectVersion).objectVersion

# Exchange Object Version (domain) - assumes single domain forest
$dc = (Get-ADRootDSE).DefaultNamingContext
$ob = "CN=Microsoft Exchange System Objects," + $dc
(Get-ADObject $ob -pr objectVersion).objectVersion

The output will looking something similar to screenshot shown below (showing the values for Exchange Server 2013 CU5):


I had an interesting one recently when submitting a certificate request to a Windows Certificate Authority using certreq.exe.  The error that came back was:

The disposition message is “Error Parsing Request The request subject name is invalid or too long. 0×80094001 (-2146877439)”

I found several links to possible solutions but, as it turns out, the problem in my case was the subject name (specified an X.500 DistinguishedName) was too long.  It seems that the CA limits the subject name field to 64 characters.  Mine was around 80 characters, which is not unusual for a DN.

The workaround is to remove the 64 character limit by running the following command:

certutil -setreg ca\EnforceX500NameLengths 0

The CA service needs to be restarted after running the command.

The Microsoft TechNet article that provides more detail can be found here.

I’ve had my Lenovo Ideapad Yoga 13 for a little over a year now. Generally, I’m very happy with it.  It has two internal SSDs, 8GB RAM and an Intel Core i7 processor.  Windows 8.1 runs very nicely on it.  I use the Ideapad for my day-to-day work as well as running test labs in Hyper-V.  Memory is generally my main limitation with Hyper-V, but mostly I can starve the VMs of RAM as performance isn’t a key issue for me for demos and/or testing purposes.  [As an aside, Exchange 2013 is a complete resource hog and won't run nicely unless you give each machine at least 4GB of RAM, which makes running a DAG near impossible for me].   Recently, I noticed that my disk latency (average response time) on the SSD that I run the VMs off was really high (around 11,000ms).  Ok, I was running 3 VMs simultaneously, but still!  So I downloaded AS SSD Benchmark to see how my SSD was performing.  The overall result was 438, which is not great when compared with what others have posted on line with the same SSD.

as-ssd-bench M4-CT256M4SSD3 15.07.2014 8-31-44 a.m.

After some deep thinking (i.e. staring idly into space over a coffee), the idea struck me that Bitlocker might be the culprit.  So I disabled Bitlocker for that drive and tried again. The difference was significant (around 20%) without being remarkable.  Interestingly, the read times before and after were almost identical.  The write times were where the difference was appreciable.

as-ssd-bench M4-CT256M4SSD3 15.07.2014 4-29-01 p.m.

The disk is still performing slowly compared with others online.  I checked my other SSD (a Samsung) and it was also slow, so the conclusion I’ve reached is that there must be some other factor (controller?) causing the slowness.  It would be interesting to hear what others with Ideapads are seeing, or if you have any ideas on how to improve performance.  Windows 8.1 is apparently optimised for SSD use, so I haven’t found any silver bullet for speeding things up.

Despite Active Directory having been around for more than 10 years, I still find new implementations proceeding without directory service access auditing enabled.  For me, auditing of who does what, where and when in your directory is crucial information.  I can’t fully fathom why Microsoft doesn’t have it enabled with some sensible defaults out of the box, but maybe that’s just me.  If you download and install Microsoft’s Security Compliance Manager 3.0, the Domain Controller baseline contains good auditing defaults.  Anyway, here is a quick “how to” guide for enabling basic directory service access auditing in Windows Server 2012 R2 Active Directory.

Getting auditing going is done in two key steps.

  1. Configuring Group Policy with the appropriate auditing settings
  2. Configuring the System Access Control List (SACL) at the appropriate level(s) in the directory

Ok, let’s get started with the first item (Group Policy).  For this, you will need a GPO linked to the Domain Controllers OU.  You can either use the Default Domain Controllers Policy or create a new one specifically for auditing.  My preference is to leave the DDCP at its defaults and create a new GPO with the settings.

Before the days of granular auditing settings you would configure your directory service access auditing under:

Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Audit Policy


These settings belong to the dark days of pre-Windows Server 2008 when only the 9 auditing categories were available.  You don’t want to use this setting.  Instead you want to use the more granular auditing sub-categories introduced first in Windows Server 2008.

The first thing you need to do is enforce the use of the sub-categories in case someone unwittingly turns on the legacy auditing mentioned above.  To do this, enable the following setting:

Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options->Audit: Force audit policy subcategory settings….[it goes on a bit, but you get the picture]


Now we need to enable auditing for the specific sub-categories we are interested in.  To do this go to:

Computer Configuration->Policies->Windows Settings->Security Settings->Advanced Audit Policy Configuration->Audit Policies->DS Access

… and enable Audit Directory Service Access.  I would also enable Audit Directory Service Changes as that can provide you with complementary audit events, including before and after information for changed attribute values (really very useful).  Success and Failure?  Perhaps, but unless you have firm requirements to capture failure events then  just choosing Success can save the reduce the number of events generated.


Right, remember to link your new GPO to the Domain Controllers OU and that’s it for the GPO side of things.  You might be thinking that’s all you need to do, but unless you’ve done part 2 you won’t see the required events generated.

Now you might be interested in just certain parts of your directory, but if you don’t have an obvious place to begin, consider turning on audit records from the top of your domain partition.   To do this, open the Active Directory Administrative Centre (dsac).  Yes, yes, you could use dsa.msc or adsiedit.msc too.

Right-click the top of the domain tree (“contoso” in my case) and bring up the properties.  Under Extensions you will see the Security tab.  From there select Advanced and then choose the Auditing tab.  If you want to be comprehensive, I would select the Everyone security principal, set Type to Success and Applies to: This object and all descendant objects.  For the permissions, again if you want to be comprehensive, set the following:

  • Write all properties
  • Delete
  • Delete subtree
  • Modify permissions
  • Modify owner
  • All validated writes
  • All extended writes
  • Create all child objects
  • Delete all child objects


Once you have applied the changes you’re pretty much ready to go.  You should now start to see comprehensive directory access events as well as the before and after values for changed objects.



One thing you might not be aware of is that there was a bug in the RTM version of Windows Server 2012 R2 which meant that the directory service change information events did not get captured.  Of course, by now you will have your R2 servers fully patched, but just in case you are still running RTM be aware that you will need the download from KB2887595 for the change information to be available.

Bear in mind that, if you have a lot of auditing going on in your security logs on your DCs, the events are going to be overwritten pretty regularly even if you beef up the size of your security event log.  As part of defining your audit strategy you should work out your requirements for storing key events.  There are a number of ways to do that, including leveraging some kind of centralised audit collection system (or SIEM), but that’s beyond the scope of this article.