Open a Socket!

Microsoft Technet describes how to back up an AD LDS instance using either Windows Server Backup or Dsdbutil.exe.  Interestingly, the Dsdbutil method leverages the Install From Media (IFM) feature to perform the backup.  Here’s a small batch file that you can use to schedule the backup using the Task Scheduler.

@echo off
rd /s c:\backup\adlds\Instance1\ /q
%windir%\system32\dsdbutil.exe “ac i Instance1″ ifm “create full c:\backup\adlds\Instance1″ q q

Enjoy!

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.

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. 

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.

If you’ve played around with Windows Server 2008 Active Directory Domain Services, you will probably be familiar with the snapshot feature within NTDSUTIL.  The feature allows you to take snapshot of the volumes that host the AD components and to then mount the snapshot.  Once mounted, you can use DSAMAIN.EXE to expose a read-only copy of the AD database to your favourite browsing tool (LDP.EXE, ADSIEDIT.MSC, DSA.MSC, ADFIND.EXE, etc.).  The process for doing this is well documented elsewhere, so I don’t intend to reproduce it here. 

Microsoft recommends that you schedule regular snapshots, as this provides you with a quick method of checking the contents of the directory at different time slices in the past.  One advantage of this that you can quickly identify which backup to use when needing to authoritatively restore accidentally deleted AD objects from backup.

What isn’t quite so well documented it the process to schedule regular snapshots.  It took me a little while to configure this properly, so I thought I would share it with you here.

Windows Server 2008 comes with a re-vamped Task Scheduler.  You can configure tasks using both the UI as well as the command line (schtasks.exe).  I prefer to use the command line as it has the advantage of allowing you to set tasks to run under the SYSTEM account.  It is also the only option if you are using Server Core, unless you want to open the firewall to allow remote task scheduling from a computer running the full version.

Here’s the command line I use. Note that it’s all on one line - wrapped here to fit page

SCHTASKS /Create /RU SYSTEM /SC DAILY /TN MYTASKS\DS_SNAPSHOT

 /TR "%windir%\system32\ntdsutil.exe sn \"ac i ntds\" create q q" /ST 05:00

SCHTASKS /Create /s MYSERVER /U administrator /P xxxxx /RU SYSTEM /SC DAILY /TN MYTASKS\DS_SNAPSHOT

 /TR "%windir%\system32\ntdsutil.exe sn \"ac i ntds\" create q q" /ST 05:00

Last week I initiated a discussion on the ActiveDir.org mailing list about running Windows Server 2008 Domain Controllers on Server Core.  I was curious to see whether there were any good reasons why all DCs (RODCs and RWDCs) should not be run on Server Core as a best practice.   The conclusion reached was that, with the possible exception of smaller organisations, the benefits of Server Core far outweigh any limitations.

Why Server Core is a good thing

• Because it installs only a subset of the full operating system, Server Core provides a smaller surface area for potential security compromise.
• Server Core requires fewer patches, thereby reducing both the administrative overhead and the potential risk of instability.
• Server Core has a lower system resource overhead, delivering a better bang-for-buck for your server hardware investment.
• Because of it’s small footprint, Server Core lends itself to virtualisation, again delivering a better return on your hardware investment.

Server Core sounds perfect, so why isn’t everyone using it?

• There is no UI, which means that administrators unfamiliar with the command line have to get to grips with new ways of doing things.  Having said that, you still have the option to run all of the AD admin tools remotely by running RSAT on a machine running VISTA or the full UI version of Windows Server 2008.
• DC promotion becomes a little more long-winded as it requires you to create an answer file and run DCPROMO in unattended mode.
• The .NET Framework (and hence Powershell) is not supported, which means you cannot run code locally that requires the Framework.  There are however a number of workarounds to this and changes coming in Powershell 2.0 improve the options for running cmdlets against remote computers.

Despite the minor inconveniences for administrators I would recommend using Server Core for all your Windows Server 2008 Domain Controllers.  For me benefits are too compelling not to.   I predict that as more Windows Server 2008 forests are deployed, Domain Controllers on Server Core will start to be considered best practice.  I also believe that Server Core will become the primary Windows Server platform within the next 10 years, with the full UI version either vanishing altogether or becoming marginalised for use only in small organisations. 

But then I chose Betamax over VHS, so what do I know.

Next to ADFIND.EXE, LDP is the tool I probably use most often when working with Active Directory.  It’s an LDAP client that was originally developed for use purely within Microsoft. It can be used for browsing, searching and making changes via the LDAP protocol.  Because of its usefulness, Microsoft included LDP in the Support Tools in Windows 2000 and Windows Server 2003.  It has now gone mainstream and is included as part of the Windows Server 2008 installation. 

Here are some of the improvements I have become aware of in the Windows Server 2008 version of LDP.  Note that with the exception of the help documentation, these improvements were first introduced in the versions of LDP that shipped with ADAM in Windows Server 2003 R2 and with the ADAM SP1 download.

Bind as currently logged on user

The long-winded method of getting going with LDP is to Connect and Bind using those options from the Connection menu and fill in all the boxes.  With the Windows Server 2000 and 2003 versions of LDP if you simply want to connect and bind to a DC in the domain that you are already logged into then you don’t need to both with all that.  You simply select Bind from the Connection menu, leave all the boxes empty and then select OK, as shown below.

That’s it - you are then bound to an in-site DC using your current credentials.  There is no need to use the Connect option, unless you need to target a specific DC or port number.

Windows Server 2008 makes this “bind as currently logged on user ” option explicit by a modification to the Bind dialogue options, as shown below.

The behaviour is otherwise the same as the Bind method in earlier versions of LDP.

SID Lookup

With LDP you can lookup an object in the directory based on its security identifier (also known as the objectSid attribute).  The method for doing this is convoluted and involves specifying the SID value as the search base using a special syntax in the form <SID=<objectSid>>, e.g. <SID=S-1-5-21-2596592837-3109173549-302247358-1116>.  For this to work the search scope needs to be set to Base, as shown below.

Windows Server 2008 makes the whole process of SID lookup much easier.  You can still use the method shown above, but there is now also a separate SID Lookup option within the Utilities menu.  This is much quicker if you simply need to resolve the SID to the friendly name.  The screenshot below shows the new feature.

ACL Editor

The version of LDP included with Windows Server 2008 delivers the ability to edit object security descriptors (see screenshot below).  Previous versions of LDP allowed you to view but not edit DACLs and SACLs.

Help Documentation

In earlier versions of LDP help comes in the form of a 13.3MB file by the name of LDP.DOC.  While the information in the file is comprehensive and useful, very few people knew of its existence.  The documentation for the Windows Server 2008 version of LDP is now fully integrated into Windows Help and Support.

There may well be other improvements within the utility that I am not aware of.  If you’re not already familiar with LDP I recommend you take the time get to know it.  It seems that Microsoft is committed to maintaining the tool and extending its capabilities.