Open a Socket!

If you’ve spent some time with Vista or Windows Server 2008 you’ll have noticed that there are some fundamental changes to the event viewer.  One of the changes is in the way in which event logs can be filtered.  In addition to the point-and-click filter selection you can now also enter an xpath query by accessing the XML tab (see screenshots below).  This gives you the ability to filter using a much wider range of criteria.  Basically, you can search using anything that is presented in the list of XML values.

-

The xpath queries take a bit of getting used to and as yet there don’t appear to be many publicly available examples.  Here are a few to get you started. This query searches the Security Event log for 4624 events that include a TargetUsername of “User1″ and corresponding to a logon type of “2″ (interactive). 

<QueryList>
  <Query Id=”0″ Path=”Security”>
    <Select Path=”Security”>*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’] and (EventID=4624)] and EventData[Data[@Name=’TargetUserName’]=’User1′] and EventData[Data[@Name=’LogonType’]=’2′]]</Select>
  </Query>
</QueryList>

The query below also looks for 4624 events, but this time for those that include a WorkstationName of “Workstation1″ and a logon type of “3″ (network). 

<QueryList>
  <Query Id=”0″ Path=”Security”>
    <Select Path=”Security”>*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’] and (EventID=4624)] and EventData[Data[@Name=’WorkstationName’]=’Workstation1′] and EventData[Data[@Name=’LogonType’]=’3′]]</Select>
  </Query>
</QueryList>

Even though Xpath can appear a little daunting at first it is worth spending a bit of time with as it’s potentially quite powerful.  As with Powershell it is something that is likely to be here to stay.

I really like the snapshot feature of Windows Server 2008 AD and have been using it quite a bit recently.  This week I had my first foray into snapshotting with AD LDS.  Everything is pretty much the same as for AD, the only obvious difference being that you can create the snapshots using either dsdbutil or ntdsutil with AD LDS.  I was somewhat surprised then to see a nasty looking error (see below) when I fired up Dsamain.exe to expose my freshly taken AD LDS snapshot.

C:\>dsamain -dbpath “C:\$SNAP_200904031033_VOLUMEC$\Program Files
\Microsoft ADAM\INSTANCE1\data\adamntds.dit” -ldapport 15005
EVENTLOG (Error): NTDS Database / Internal Processing : 1168
Internal error: An Active Directory Domain Services error has occurred.Additional DataError value (decimal):
-1507Error value (hex):
fffffa1d

Internal ID:
20208a9

EVENTLOG (Error): NTDS General / Internal Processing : 1003
Active Directory Domain Services could not be initialized.

The directory service cannot recover from this error.

User Action

Restore the local directory service from backup media.

Additional Data

Error value:
-1507 JET_errColumnNotFound, No such column

EVENTLOG (Informational): NTDS General / Service Control : 1004
Active Directory Domain Services was shut down successfully.

After a few minutes bafflement, I had another look through the Dsamain.exe command line options and saw this:

 -adlds       (optional) open AD/LDS DIT

It turns out the -adlds parameter is optional only in the sense that you don’t (and in fact must not) include it when using Dsamain.exe with AD.  It is mandatory when using AD LDS.

Once I included the -adlds parameter everything fired up normally.   Another case of RTFM for me.

You may have heard via the grapevine, or even via the Beta program for that matter, that Windows Server 2008 R2 will ship with an Active Directory Module for Powershell.  Having seen some of the capabilities at the recent MVP Summit, I am very impressed with the work the product team has done in this area. 

Now you may be thinking that Powershell is soooo (Exchange) 2007 - and why have we had to wait so long for AD Cmdlets from Microsoft?  The truth is that, despite having been in the pipeline for some time, the Directory Services product team has had other priorities. 

To give you a head start with Powershell in advance of the R2 release, check out the new Active Directory Powershell Blog.

I’m finding there is a huge gulf between playing with Windows Server 2008 in a lab and working with it in a production environment. The biggest difference for me is that I typically use a built-in Administrator account in the lab environment, but work with an account with delegated permissions in production. This means I encounter…er…challenges with User Account Control (UAC) on a fairly regular basis. I have already blogged about some scenarios in which UAC doesn’t error or fail gracefully here, here and here.

Today’s blog entry is all about the following UAC-related Group Policy setting:

Computer Configuration -> Windows Settings -> Security Settings -> Local Polices -> Security Options -> User Account Control: Run all administrators in Admin Approval Mode

Enabled by default, this setting basically forces all users, including Administrators to run as standard users. Any tasks that need to be run as Administrator have to be launched with elevated privilege. It is a setting that is entirely sensible from a security perspective, but can cause frustration and confusion in certain situations. Here’s an example scenario.

Let’s say you are logged into a Windows Sever 2003 (or Vista) machine with an account that is a member of the local Administrators group. By default the Administrators group has Full Control permissions over files and folders on the machine. With the above-mentioned Group Policy enabled, however, you may not be able to, for example, create new text files by right-clicking within Windows Explorer (unless you have rights to do so through either explicit permissions or through membership of other groups).  For example, when right clicking in the root of C:\ you are only likely to have the ability to create a new folder by default, as shown below.

No problem, you might think, my account is a member of the local Administrators group so I’ll just fire up Windows Explorer in elevated mode by right-clicking the icon and choosing “Run as Administrator”. Doing this gives all the appearance of running in elevated mode, but in reality does nothing.

So how the heck do you create new text files? Or, for that matter, how do you do all those other things that require elevated privileges that you typically would do from within Windows Explorer in earlier versions of the OS? Well, there may be other methods, but the workaround I found was to open Notepad in elevated mode. Then from within Notepad select File -> Open and this gives you, effectively, an elevated Windows Explorer to work with, as shown below.

Another option would be to open a command window using “Run as Administrator” and create the text file from there.  You could then edit and save it using an elevated Notepad session.   Again, a rather clumsy workaround for something that you did without thinking in previous versions of the OS.

 If nothing else, UAC in Windows Server 2008 and Vista forces you to think outside the box. The old ways in which you used to work with the user interface in earlier versions of the OS may no longer apply. I can be deeply frustrating, but I suspect UAC is here to stay because of the security benefits it delivers. We may as well get used to it.

Okay, okay, I realise that I may be labouring the point somewhat.  I’ve already written two blog entries (here and here) about UAC in Windows Server 2008 and this is the third and (probably) last.

When you check DC replication using the repadmin /showreps command from a privileged command window you might see something like this:

SITE1\DC1
DSA Options: IS_GC

Site Options: (none)

DSA object GUID: 0f28ec82-687f-4a16-81fb-bc7dc6b67fa9

DSA invocationID: 498ceb24-0a84-40a9-b8cb-63b1ff9a8ed1

==== INBOUND NEIGHBORS ======================================

DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

CN=Configuration,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

CN=Schema,CN=Configuration,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

DC=ForestDnsZones,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

DC=DomainDnsZones,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

Howerver, when you run the same command from an unprivileged command window, you might see the error shown below.

SITE1\DC1

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: 0f28ec82-687f-4a16-81fb-bc7dc6b67fa9

DSA invocationID: 498ceb24-0a84-40a9-b8cb-63b1ff9a8ed1

==== INBOUND NEIGHBORS ======================================

DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

CN=Configuration,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

CN=Schema,CN=Configuration,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

DC=ForestDnsZones,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

DC=DomainDnsZones,DC=MYCO,DC=COM

SITE0\DC2 via RPC

DSA object GUID: 04f70cfc-c73d-4e3c-9c8f-42c3ad146bb2

Last attempt @ 2009-02-04 13:48:49 was successful.

DsReplicaGetInfo() failed with status 8453 (0x2105):

Replication access was denied.

DsReplicaGetInfo() failed with status 8453 (0x2105):

Replication access was denied.

Note that the information returned is identical.  The only difference is that you see the errors at the end when running in an unprivileged window.  I believe the errors relate to a missing “Monitor Replication Topology” extended right at the root of each of the directory naming contexts (partitions).

 As with other UAC annoyances, the errors can potentially be confusing.  I guess the moral of the story with Windows Server 2008 is to always be aware of when you need to run commands with full privileges.  In my case it clearly takes some getting used to. 

Yesterday I blogged about some of the confusion that Windows Server 2008 User Account Control can cause.  Continuing on the same theme, here is another example - this time using slmgr.vbs to query the licence activation status of a Windows Server 2008 machine.

This is what you see when you run the command line from a command window that was opened without elevated privileges.

cscript %windir%\system32\slmgr.vbs -dli

Name: Windows Server(R), ServerStandard edition
Description: Windows Operating System - Windows Server(R), VOLUME_KMSCLIENT channel
Partial Product Key: BFGM2
License Status: Licensed
Volume activation expiration: 250200 minute(s) (173 day(s))

Key Management Service client information
    Client Machine ID (CMID): 3af05e3c-b291-47ad-bbf9-cc6278b3c923
    DNS auto-discovery: KMS name not available
    KMS machine extended PID: 55032-00152-339-003838-03-5129-6001.0000-0062009
    Activation interval: 120 minutes
    Renewal interval: 10080 minutes

As you can see, the name of the Key Management Server (KMS) is unavailable, which is not very helpful if you are trying to troubleshoot a KMS issue. 

But now look what happens when you run the same command as Administrator (i.e. with elevated privleges).

Name: Windows Server(R), ServerStandard edition
Description: Windows Operating System - Windows Server(R), VOLUME_KMSCLIENT channel
Partial Product Key: BFGM2
License Status: Licensed
Volume activation expiration: 250200 minute(s) (173 day(s))

Key Management Service client information
    Client Machine ID (CMID): 3af07e3c-b291-47ad-bbf9-cc6278b3c923
    KMS machine name from DNS: kms1.contoso.com:1688
    KMS machine extended PID: 55032-00152-339-003838-03-5129-6001.0000-0062009
    Activation interval: 120 minutes
    Renewal interval: 10080 minutes

In this case the name of the KMS server is shown correctly.

I think it would be more helpful if, in the first example above, the whole command were to fail with an error indicating that elevated privileges are required to successfully complete the command.  The fact that the command partially completes only causes confusion.

I’ve been working with both Vista and Windows Server 2008 for quite a while now, but I still manage to fall foul of User Account Control, especially when working from the command prompt.  As you will no doubt be aware, there are certain tasks that need elevated privileges and these require you to open the command window as Administrator (you do this by right-clicking the command prompt icon and selecting “Run As Administrator”).

If you try to run tasks that require elevated privilege in a normal (i.e. unprivileged) command window, one of two things will happen.  Either the command that you are attempting to run will tell you that it requires elevated privileges, or it will fail with an (often obscure and unhelpful) error message.  Here’s an example.

The other day I wanted to run the Active Directory Schema MMC snap-in (schmmgmt.msc) on a DC.  To access the snap-in you first need to register a dll named schmmgmt.dll.  The command to do this is:

 regsvr32 schmmgmt.dll

On a Windows Server 2008 machine this activity requires elevated privileges, so you need to run the command as Administrator.  If you don’t, you will see the error below.

The module “schmmgmt.dll” was loaded but the call to DllRegisterServer failed with the error code  0x80040201

It took me a good few minutes to work out what I had done wrong. Doh!  Hopefully I’ll eventually get the hang of User Account Control.

Most people are (quite rightly) terrified of seeing a whole bunch of errors in the DS event log following a schema update.   This happened to me in a lab environment at a customer recently and I thought I would share the information here.

I ran Windows Server 2008 adprep /forestprep on a Windows Server 2003 SP1 DC.  All seemed to go well and the schema update completed successfully.  Before moving on I checked the Directory Service event log and found a large number of 1136 error events.  There were effectively two events that were recurring, as shown below.

Event Type: Error
Event Source: NTDS General
Event Category: DS Schema
Event ID: 1136
Date:  23/01/2009
Time:  1:02:38 p.m.
User:  NT AUTHORITY\ANONYMOUS LOGON
Computer: DC1
Description:
Active Directory failed to create an index for the following attribute.
�
Attribute identifier:
591789
Attribute name:
msFVE-RecoveryGuid
�
A schema cache update will occur 5 minutes after the logging of this event and will attempt to create an index for the attribute.
�
Additional Data
Error value:
-1403 JET_errIndexDuplicate, Index is already defined

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: NTDS General
Event Category: DS Schema
Event ID: 1136
Date:  23/01/2009
Time:  1:01:53 p.m.
User:  NT AUTHORITY\ANONYMOUS LOGON
Computer: DC1
Description:
Active Directory failed to create an index for the following attribute.
�
Attribute identifier:
591822
Attribute name:
msFVE-VolumeGuid
�
A schema cache update will occur 5 minutes after the logging of this event and will attempt to create an index for the attribute.
�
Additional Data
Error value:
-1403 JET_errIndexDuplicate, Index is already defined

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. 

Some Googling revealed the problem to be to do with a combination of the BitLocker Drive Encryption schema updates that are included as part of the Windows Server 2008 schema extensions together with certain language locales (New Zealand English in my case).

The resolution of the issue involves removing the CONTAINER_INDEX setting within the searchFlags attribute value of the msFVE-VolumeGuid and msFVE-RecoveryGuid attribute schema objects.  To do this you can use ADSIEdit to modify the value for both attributes from 27 to 25, as shown in the screenshot below.

Once the modifications have been made, the errors no longer recur.

Interestingly, I could not reproduce the problem when running Windows Server 2008 forestprep on a Windows Server 2003 R2 SP2 DC with the same language locale.

For more information see the Microsoft KB article below.

Error messages after you install the BitLocker Drive Encryption schema updates in a Windows Server 2003 domain

It’s been a while, but Joe Richards has released a new version of his most excellent (and free!) command line tool, ADFIND.  This latest version is V01.39.00 and incorporates a number of new features, switches and shortcuts.  Check it out here.

The other day I had a need to configure scheduled backups of GPOs to file on a Windows Server 2008 Domain Controller.  Aha (I thought), I’ve done this before using the BackupAllGPOs.wsf script that is included along with a whole bunch of other handy scripts when you install the Group Policy Management Console (GPMC).  After a few minutes of fruitless searching on my Windows Server 2008 DC I realised that although the GPMC was installed (as a feature) the scripts were nowhere to be found.  After some Googling I found out that I hadn’t been singled out for victimisation - unlike Windows Server 2003, the scripts just aren’t installed by default in Windows Server 2008 when you enable the GPMC feature.  I discovered that you could download the Vista and Windows Server 2008 versions of the scripts here:

Group Policy Management Console Sample Scripts

It puzzled me that the scripts weren’t included by default.  I suspect the Vista and WS2008 versions of the scripts were developed after the products had shipped.  Anyway, it made me think that Microsoft maybe wanted me to work with PowerShell and not VBScript.  Aha (I thought again), I’ll see if I can find the PowerShell equivalent of the GPMC scripts.  After a fair bit of searching I found two options.

Option 1.

SDM GPMC PowerShell Cmdlets from Darren Mar-Elia

Option 2.

Sample functions provided by Thorbjörn Sjövold in his Technet Magazine article, Simplify Group Policy Administration with Windows PowerShell

The first option requires installing the Cmdlets from an .msi install package, something I didn’t really want to have to do in the environment I was working with.

The second option proved a winner and provided the functions I needed to get my PowerShell script up and running within a few minutes.  Here’s my script to backup all the GPOs in a given domain. 

## FileName: BackupGPOs.ps1
## Date: 13.12.2008
## Purpose:  Backs up all GPOs within domain to file

## Variables

$backupDirectory = “c:\backup\GPO”
$domainName = [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Name

## Functions

# Source: http://technet.microsoft.com/en-us/magazine/cc162355.aspx

###########################################################################
# Function   : BackupAllGpos
# Description: Backs up all GPOs in a Domain
# Parameters : $backupDirectory - The directory where the backups will be stored
#            : $domainName - The dns name, e.g. microsoft.com, of the domain to operate on
#            : $backupComment - An optional comment for the backups, if nothing is passed the current date will be
used.
# Returns    : N/A
###########################################################################
function BackupAllGpos(
  [string] $backupDirectory=$(throw ‘$backupDirectory is required’),
  [string] $domainName=$(throw ‘$domainName is required’),
  [string] $backupComment=$(get-date))
{
  $gpmAllGposInDomain = GetAllGposInDomain $domainName

  foreach ($gpmGpo in $gpmAllGposInDomain) # Iterate through all the GPOs
  {
    “Back up GPO : ” + $gpmGpo.DisplayName
    $gpmResult = $gpmGpo.Backup($backupDirectory, $backupComment) # Backup the GPO
    [void] $gpmResult.OverallStatus
    $gpoBackup = $gpmResult.Result
  }
}

###########################################################################
# Function   : GetAllGposInDomain
# Description: Returns all GPOs in a domain
# Parameters : $domainName - The dns name, e.g. microsoft.com, of the domain to operate on
# Returns    : All Group Policy Objects in the supplied domain
###########################################################################
function GetAllGposInDomain(
  [string] $domainName=$(throw ‘$domainName is required’))
{
  $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
  $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
  $gpmDomain = $gpm.GetDomain($domainName, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed using any DC
  $gpmSearchCriteria = $gpm.CreateSearchCriteria() # Create a search criteria without any restrictions
  $gpmDomain.SearchGPOs($gpmSearchCriteria) # Search and find all GPOs in the domain, this will return the array
}

## Main

backupAllGpos $backupDirectory $domainName

## End

Note that I’ve set the $domainName variable to match the domain of the computer from which the script is run.  To set the variable to match the domain of the user account under which the script runs change it to (may wrap):

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

The sample functions provided by Thorbjörn are comprehensive and cover nearly all of the features included in the original GPMC VBScripts.  I encourage you to take a look.