Category: Uncategorized

Posted on

How install from media (IFM) really works (Part 1)

This is the first blog post in a series of posts covering how the “Install from media” feature really works, it’s an in-depth very technical post that explains what happens under the hood and this first part focuses on how it works in Windows Server 2003.

Background

Install from media was first introduced in Windows Server 2003, as a solution to improve the installation experience of newly promoted domain controllers in branch offices mainly (or sites with slow-links where the initial replication could take significant time to complete), but it is actually an important component in many disaster recovery plans I have designed for various customers over the years, As it is a fast and efficient way to re-install a domain controller and get it up to sync, (that’s the proper way to handle a faulting replicas/domain controllers in most cases). There is some common misunderstandings of the concept “Install from media” I terms of if the operation could be performed entirely offline or online, the short answer is: No. It can’t be performed offline; you have to be online with at least one writable domain controller in the same domain as the IFM source is taken from and even then you may not be able to be fully efficient and cause replication to happen over the network anyway, this need some future explanation.

What dose Install from media (IFM) consist of

Install from media (IFM) contains two important things.

  • NTDS.DIT (Active Directory Database) – at the time the IFM is generated (Regardless of Windows Server 2003, Windows Server 2008 or later –the NTDS.dit is pretty much unchanged until DCPROMO makes a lot of changes at the becoming domain controller that takes use of the database – it will change the DSA reference and update related “instance specific” information in the hidden table )
  • SYSVOL (SYSVOL GPT Storage)
  • Registry (Contains the SYSKEY used to decrypt the PEK (also known as Password Encryption Key) that efficiently ensure that the protection for sensitive information stored in the Active Directory database (Such as Password Hashes) are unique to each instance of the database (read each domain controller) –Note: This doesn’t apply to RODCs .

Sourcing install from media (IFM) using System State and VSS

Sourcing the media used by IFM is different in Windows Server 2003 (all versions) and Windows Server 2008 and later, the difference is the technology used to gather information required.

  • Windows Server 2003 IFM media is generated by performing a system state backup, the reason for this is that we can get a copy of ntds.dit while we’re up and running DsIsNTDSOnline=True (Active Directory is operational) this is archived by the DsBackup API: http://msdn.microsoft.com/en-us/library/ms675896(VS.85).aspx.We will also get a copy of SYSVOL since a system state backup contains the following:
    • Active Directory
    • The SYSVOL tree
    • The Boot.ini file
    • The COM+ class registration database
    • The registry

    To be more specific the following is required in the system state in order to be able to source IFM:

    • Active Directory is required.
    • The SYSVOL tree may be optionally removed. (A specific configuration is required to source the SYSVOL tree during IFM promotion)
    • The Boot.ini file may be removed.
    • The COM+ class registration database may be removed.
    • The registry folder is required. Registry components are required as follows:
      • The Default file in the Registry folder may be removed.
      • The SAM file is required.
      • The SECURITY folder is required.
      • The SOFTWARE file may be removed.
      • The SYSTEM file is required.

    We’re are responsible for doing a restore of a system state backup or selves to an alternative location, and ensure we gather the required information above. (Optionally if we care about disk size optimization we can not only select the specific components required in the system state backup, but we could also perform a offline defragmentation of the ntds.dit database)

    We can only use IFM to promote domain controllers in the same domain as we sourced it from, as well the target domain controller has to be running the same operating system, including service pack and architecture (x86/x64)

    Sourcing the NTDS.DIT – Active Directory database from IFM in Windows Server 2003

    As explained earlier in this article the Active Directory database (NTDS.dit) is being backup either by the DsBackup API or VSS API – The Active Directory database are unique to each DC and contains the NCs hosted by the DC typically Domain, Schema, Configuration and in some cases NDNC’s also known as application partitions such as DomainDNSZones and ForestDNSZones, if the DC is also a GC it will contain partial information about every object in all domain NCs in the entire forest (a multiple domain forest) – even thou if a DC are a GC in a single domain environment, the domain NC is only stored once in the database, if the sourced database was a GC, the computer being promoted to a DC using the source will also become a GC.

    During the backup itself (even if the intent are for IFM) – No changes are made to the database except setting the backup expiration date and backup usn in the hidden record. (Also known has the hidden table). Changes are instead modified/adjusted during DCPROMO on the computer that are about to become a DC using the sourced database from IFM.

    Before we can have an in-depth look at the changes that take place inside the Active Directory database during IFM we need to understand the physical layout of the database and some key concepts. (Note: For the purpose of this article the NTDS.dit physical layout will be rather simplified than the real/exact layout for display purposes)

    The Active Directory database (NTDS.DIT) contains the following tables.

    Table 1: NTDS.DIT Database Layout (Simplified Version)

Table

Description
datatable Contain: Domain, Schema, Config and NDNCs as well partial NCs and basically every object and phantom.
hiddentable Contains the DSA identity and various related information
linktable N/A – Out of scope for this article
quota_rebuild_progress_table N/A – Out of scope for this article
quota_table N/A – Out of scope for this article
sdproptable N/A – Out of scope for this article
sd_table N/A – Out of scope for this article
  • Ensure the database isn’t out-dated aka older than Tombstone Life Time (TSL)
    During DCPROMO the sourced IFM database are verified that it hasn’t passed the Tombstone Life Time (TSL) in the forest, if the database is older than the TSL, the promotion is aborted. This is more specifically measured against the object who had the last USN Change and it’s when-changed date.

  • Change/Adjust the DSA – Directory Service Agent IdentityThe “hiddentable” also known as the hidden record contains the identity of the local DSA – Directory Services Agent (DC) hosting the instance of the database, this identity points to the DCs NTDSA object within the directory stored within the “datatable”, the ntdsa object in its turn contains necessary information such as the DMD to be able to read the schema and soon. (I will write another article on how this works – more in detail). When it comes to IFM, the DSA identity stored in the hidden record/hidden table still points to the identity of the DC the IFM was sourced from, this cause an issue.The following illustrates the relationship between the DSA identity in the “hiddentable” and the NTDS Settings object stored in the “datatable” – that’s actually the NTDS Settings object you will see under the server object in Active Directory Sites and Services.

    Table 2: NTDS.DIT “datatale” (Simplified Version)

    So in this example NTTEST-SCH-01 is the DC where we sourced the IFM (backed up the database) – Now how do we get the new identity of the computer being promoted to a DC using the sourced IFM media? Well the new DSA for the computer being promoted is actually created remotely during DCPROMO on another DC (at the DC we perform the initial replication with, specified in the unattended answer file as “ReplicationSourceDC” parameter) , before we can change the record in the “hiddentable” to point to it – we must replicate in the newly created DSA by replicating the Configuration NC – this can cause an issue by itself – If we’re preforming the initial replication with the DC we sourced the IFM from, we’re temporarily presenting us self as the very same DC and replication will fail.

    So how are this solved? We’re creating a temporary “dummy” DSA with a corresponding server object in the database, retire invocation IDs, copying all references to NCs hosted by the old DSA (Doing not will have KCC to trigger a deletion of those sourced NCs later on), the temporary “dummy” DSA are created in the any site and the first site in alphabetical order identified.

    Now we can re-initialize and successfully replicate in the remotely created DSA by replicate the configuration NC using the temporary “dummy” DSA identity, retire invocation IDs, copying all references to NCs hosted by the temporary “dummy” DSA (Doing not will have KCC to trigger a deletion of those sourced NCs later on) we can now remove the temporary “dummy” DSA and store the real identity of the computer being promoted in the “hiddentable”

    We can now re-initialize as our self’s with our real DSA identity and continue processing.

  • Remove None-Replicated attributes from the database.
    Non-replicated attributes (Containing bit 0x00000001 in System-Flags) , such as badPwdCount, Last-Logon, and Last-Logoff are stored on each domain controller, but are not replicated. The non-replicated attributes are attributes that pertain to a particular domain controller, as those attributes contains local information associated with the DC that the IFM was sourced from, those are deleted except the following:
  1. DS-Core-Propagation-Data: http://msdn.microsoft.com/en-us/library/ms675655(v=VS.85).aspx
  2. Obj-Dist-Name: http://msdn.microsoft.com/en-us/library/ms675516(v=VS.85).aspx
  3. ms-DS-ReplicationEpoch: http://msdn.microsoft.com/en-us/library/ms677478(v=VS.85).aspx
  4. Object-GUID: http://msdn.microsoft.com/en-us/library/ms679021(v=VS.85).aspx
  5. Partial-Attribute-Deletion-List: http://msdn.microsoft.com/en-us/library/ms679106(v=VS.85).aspx
  6. Partial-Attribute-Set: http://msdn.microsoft.com/en-us/library/ms679107(v=VS.85).aspx
  7. Prefix-Map: http://msdn.microsoft.com/en-us/library/ms679371(v=VS.85).aspx
  8. Repl-Property-Meta-Data: http://msdn.microsoft.com/en-us/library/ms679448(v=VS.85).aspx
  9. Repl-UpToDate-Vector: http://msdn.microsoft.com/en-us/library/ms679450(v=VS.85).aspx
  10. Sub-Refs: http://msdn.microsoft.com/en-us/library/ms679895(v=VS.85).aspx
  11. USN-Changed: http://msdn.microsoft.com/en-us/library/ms680871(v=VS.85).aspx
  12. USN-Created: http://msdn.microsoft.com/en-us/library/ms680924(v=VS.85).aspx
  13. When-Changed: http://msdn.microsoft.com/en-us/library/ms680921(v=VS.85).aspx
  14. Pek-List: http://msdn.microsoft.com/en-us/library/ms679109(v=VS.85).aspx
  15. msDS-NcType: http://msdn.microsoft.com/en-us/library/cc220312(v=prot.10).aspx
    • Decrypt and Re-encrypt the Password Encryption Key (PEK)
      Secret Data stored within the Active Directory database (NTDS.DIT) such as the password hashes are additionally protected by a Password Encryption Key (PEK) – the PEK are encrypted by the SYSKEY of the DC and are therefore unique to each DC, the sourced NTDS.dit from the IFM contains a PEK encrypted by the SYSKEY from the DC on which the IFM was generated (the computer where the NTDS.dit was backed up). DCPROMO will decrypt the PEK using the SYSKEY (from the DC the IFM was sourced from) from the registry in the restored IFM information as the SYSKEY are stored in the registry (that’s one reason why we need to include parts of the registry in IFM) and then re-encrypt the PEK with the SYSKEY of the computer being promoted to DC.

 

  • Diagnostics and Logging
    IFM promotions can be identified in the Dcpromo.log and Dcpromoui.log files that are located in the %systemroot%debug folder. There are several entries that can be used to verify that the database where sourced from the IFM and that the promotion did use IFM.

    Table 3: DCPROMO.log

DCPROMO.log
07/03 06:35:29 [INFO] Copying restored Active Directory files from C:IFM_MEDIAActive Directoryntds.dit to C:WINDOWSntdsntds.dit…
07/03 06:35:29 [INFO] Copying restored Active Directory files from C:IFM_MEDIAActive Directoryedb00001.log to C:WINDOWSntdsedb00001.log…
07/03 06:35:29 [INFO] Active Directory is initializing the restored database files. This might take several minutes.

Table 4: DCPROMOUI.log

DCPROMOUI.log
dcpromoui AAC.AB0 0271 Enter State::ReplicateFromMedia true
dcpromoui AAC.AB0 0272 Enter State::GetReplicationSourcePath C:IFM_MEDIA

Sourcing NDNCs with Windows Server 2003 is only supported by Windows Server 2003 SP1 or later under the following conditions:

  • Both the DC your souring the IFM from must be running Windows Server 2003 SP1 or later and as well the machine intending to become a DC using the source IFM.
  • The forest functional level (FFL) has to be: Windows Server 2003 (Pre-Windows Server 2003 FFL adding replicas to NCs has to be done on the Domain Naming Master – FSMO)
    Note: The promotion completes with the sourced IFM even if the forest functional level (FFL) is less than Windows Server 2003 but NDNCs aren’t sourced from the IFM and the following will happen:
  1. The following will be logged in the Directory Services Log: “The forest functional level is not high enough to complete addition of application directory partitions during installation of the directory. Therefore specified application directory partitions will not be added to this domain controller during installation. If you would like to make this server a replica of an application directory partition, you could re-add these application partition after the installation is complete.”
  2. The following will be logged in the Directory Services Log, and the DC will begin the process of physically removing the NDCs source from the IFM in the DCs database: “The local domain controller is no longer configured to host the following directory partition. As a result, the objects in this directory partition will be removed from the local Active Directory database.” Note: In this case the DomainDNSZones and ForestDNSZones NDNCs.
  3. The DomainDNSZones and ForestDNSZones are begin replicated in again over the wire using normal replication, as the promoted DC (Sourced from IFM) hosts the DNS Service: As a result of this the DC (Sourced from IFM) has to obtain a new invocationID once again (It has already done this once for using the sourced IFM database instance):
    Note: This can be confirmed by running the repadmin /showsig command

    Default-First-Site-NameNTTEST-SCH-02

    Current DC invocationID: 7bbd4543-cf19-44e3-9638-96907ceb8a36 ß Current InvocationID obtained cause of removing/adding NDCs.

    28081325-eee8-40b0-9587-9c02867040bc retired on 2011-07-03 07:16:41 at USN 32780 ß New InvocationID representing the sourced IFM restored/promoted as a new instance on the current DC

    b7633426-242b-47bf-852c-a07466ef937f retired on 2011-07-03 06:35:39 at USN 16397ß InvocationID representing the instance on the DC where the IFM where sourced

  • You have to use an unattended answer file specifying the ReplicateFromMedia=Yes parameter as well define the ApplicationPartitionsToReplicate parameter, note this can be used to include specific NDNCs or you can simply include them all by specific a wildcard, Here are some samples:
    • ApplicationPartitionsToReplicate=*
    • ApplicationPartitionsToReplicate=”DC=DomainDNSZones,DC=corp,DC=company,DC=com” “DC=ForestDNSZones,DC=corp,DC=company,DC=com”

Sourcing SYSVOL with IFM at Windows Server 2003:

The File Replication Service (FRS) can source files and folders from the restored system state backup on the first restart after a DCPROMO IFM promotion if the strict dependencies that the File Replication Service (FRS) requires are fulfilled.

  • The system state backup must contain MD5 checksum data that is used by the File Replication Service (FRS) to determine if a restored file or folder is the same as the file versions on existing domain controllers in the domain.
  • The File Replication Service (FRS) must have constructed MD5 checksum data for the files in the SYSVOL tree.
    For MD5 checksums to exist, files and folders in the SYSVOL tree must have been replicated at least one time after there were two or more domain controllers in the domain (Note: The SYSVOL can never be efficiently sourced from a IFM media also known as System State Backup in Windows Server 2003 unless there is at least two DCs in the domain already present at the point when the IFM media also known as System State Backup is generated). You can trigger FRS to store the MD5 checksum of all files in the SYSVOL tree my writing a script that modifies the files, for example set/un-set the hidden attribute, that simply will tiger a replication.Furthermore the MD5 checksum data is stored in ntfrs.jdb ESE database that’s by default located in “%SystemRoot%ntfrsjet”. The ntfrs.jdb ese database are using 4k pages and have the following layout.Table 5: NTFRS.JDB Database Layout
Table

Columns
ConfigTable N/A – Out of scope for this article
CXTIONTable00000 N/A – Out of scope for this article
CXTIONTable00001 N/A – Out of scope for this article
DIRTable00000 N/A – Out of scope for this article
DIRTable00001 N/A – Out of scope for this article
IDTable00000 FileGuidFileID

ParentGuid

ParentFileID

VersionNumber

EventTime

OriginatorGuid

OriginatorVSN

CurrentFileUsn

FileCreateTime

FileWriteTime

FileSize

FileObjID

FileIsDir

FileAttributes

Flags

ReplEnabled

TombStoneGC

OutLogSeqNum

Spare1Ull

Spare2Ull

Spare1Guid

Spare2Guid

FileName

Spare1Wcs

Spare2Wcs

Spare1Bin
IDTable00001 N/A – Out of scope for this article
INLOGTable00000 N/A – Out of scope for this article
INLOGTable00001 N/A – Out of scope for this article
OUTLOGTable00000 SequenceNumberFlags
IFlags
State
ContentCmd
Lcmd
FileAttributes
FileVersionNumber
PartnerAckSeqNumber
FileSize
FileOffset
FrsVsn
FileUsn
JrnlUsn
JrnlFirstUsn
OriginalReplica
NewReplica
ChangeOrderGuid
OriginatorGuid
FileGuid
OldParentGuid
NewParentGuid
CxtionGuid
Spare1Ull
Spare2Ull
Spare1Guid
Spare2Guid
EventTime
FileNameLength
Spare1Wcs
Spare2Wcs
Spare1Bin
Spare2Bin
FileName
OUTLOGTable00001 N/A – Out of scope for this article
VVTable00000 N/A – Out of scope for this article
VVTable00001 N/A – Out of scope for this article

The MD5 checksum are stored in the IDTable0000X and are stored in the column Spare1Bin.
You can validate the existence of MD5 checksums by using “ntfrsutil idtable > MD5Hash.txt” and search for entries missing hashes.


Table 6: NTFRS.JDB IDTable

IDTable
Table Type: ID Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
FileGuid : 790adf00-7709-447d-9a756b655931151b

FileID : 00030000 00002bb9
ParentGuid : 9fe6d1af-dac8-40be-bd06e6030f4a6ae0

ParentFileID : 00050000 00002874

VersionNumber : 00000003

EventTime : Sun Sep 11, 2005 03:36:18

OriginatorGuid : 5ab8b3e3-27e8-4c9e-a5e152246f57df61

OriginatorVSN : 01c5b0b1 ad0a2413

CurrentFileUsn : 00000000 011a3e88

FileCreateTime : Sun Aug 7, 2005 23:40:01

FileWriteTime : Sun Sep 11, 2005 03:36:18

FileSize : 00000000 00002000

FileObjID : 00000000-0000-0000-0000000000000000

FileName : CorpLogon.vbs

FileIsDir : 00000000

FileAttributes : 00000020 Flags [ARCHIVE ]

Flags : 00000000 Flags [<Flags Clear>]

ReplEnabled : 00000001

TombStoneGC : Sun Aug 7, 2005 23:42:01

OutLogSeqNum : 00000000 00000000

Spare1Ull : 00000000 00000000

MD5CheckSum : MD5: b9552637 1973e4d6 84dd6de7 f3125a64

RetryCount : 0

FirstTryTime :
Table Type: ID Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
FileGuid : 127f0701-7e51-4624-b0ef801fa93bb925

FileID : 00040000 00002b7f

ParentGuid : 8bebf734-7fd2-4d66-b8548820dcb17bad

ParentFileID : 00020000 00002b7b

VersionNumber : 0000000b

EventTime : Fri Nov 13, 2009 14:46:45

OriginatorGuid : 5ab8b3e3-27e8-4c9e-a5e152246f57df61

OriginatorVSN : 01c96785 4bd8b2c5

CurrentFileUsn : 00000001 df606a48

FileCreateTime : Sat Aug 6, 2005 23:27:54

FileWriteTime : Fri Nov 13, 2009 14:46:45

FileSize : 00000000 00000020

FileObjID : 127f0701-7e51-4624-b0ef801fa93bb925

FileName : gpt.ini

FileIsDir : 00000000

FileAttributes : 00000020 Flags [ARCHIVE ]

Flags : 00000000 Flags [<Flags Clear>]

ReplEnabled : 00000001

TombStoneGC : Sat Aug 6, 2005 23:28:01

OutLogSeqNum : 00000000 00000000

Spare1Ull : 00000000 00000000

MD5CheckSum : MD5: 959cfc82 54e6ccbf 3dc74a29 7fe46a42

RetryCount : 0

FirstTryTime :
  • The SYSVOL part of the IFM media also known as the System State Backup must be restored to the same volume that is chosen to host the SYSVOL tree when you run DCPROMO, or it has to be specified to the same value in your unattended answer file.


Seeding the SYSVOL with IFM at Windows Server 2003:

Even if the SYSVOL are sourced with IFM delta changes are about to be replicated in over the network, there are certain requirements to ensure that this process are being efficient and that not the entire SYSVOL tree are replicated over the network again, once of the requirements has already been discussed in this article regarding MD5 checksums: The File Replication Service (FRS) must have constructed MD5 checksum data for the files in the SYSVOL tree.

The Domain Controller (DC) or File Replication Service Replica (FRS Replica) that the initial replication of the SYSVOL tree takes place with must meet the following requirements

  • The Domain Controller (DC) or File Replication Service Replica (FRS Replica) that the initial replication takes place with are identified by specifying the “ReplicationSourceDC” parameter in the unattended dcpromo answer file. (Note this can’t be done using the UI)

    How to best select the Domain Controller (DC) or File Replication Service Replica (FRS Replica) to perform initial replication with:

    • Locate a domain controller that has a low number of inbound and outbound connections. This domain controller must not be a significant originator or forwarder of change orders to downstream partners in SYSVOL or FRS-replicated DFS replica sets
    • Locate a domain controller that doesn’t act as Bridgehead server (those typically have many replication partners)
  • The File Replication Service (FRS) outbound log on the DC/FRS replica that is used to seed the SYSVOL tree with must be cleared so that a full vvjoin is triggered when the initial synchronization of SYSVOL with the IFM promoted DC occur, the reason for this is that if the outbound log contain cached items, an optimized vvjoin is performed and optimized vvjoin’s doesn’t support pre-staging content, this results in a full replication of the entire SYSVOL tree over the network with the IFM promoted DC instead of delta changes and new files.

    How to verify and clear the outlog:

    • At the intended helper DC (DC chosen to perform initial replication with) run:
      ntfrsutil outlog to show current entries in the outlog change cache.
      Note: See Table 5: NTFRS.JDB Database Layout for the outlog table layout earlier in this article
    • If the ntfrsutil outlog show’s entries, the outlog needs to be trimmed/reset or if the period of time specified as the “Outlog Change History in Minutes” (by default 7 days) has passed since the IFM media was generated.
      Changes the Outlog Change History In Minutes value in the following registry subkey:
      HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParameters to 0 (zero)
    • Run ntfrsutl poll /now
    • Restart the FRS Service on the actual DC/FRS replica: net stop ntfrs | net start ntfrs
    • Run the ntfrsutil outlog again, the contents of the current outbound log must contain only files that have been modified after you changed the registry and restarted the FRS.

      Note: Don’t forget to reset the Outlog Change History In Minutes registry type back to the seven-day default while you’re done with the IFM operations (e.g. all DCs intended to be promoted with IFM has been promoted)

  • Configure Debug and Analysis logging on the computer that is to be promoted using IFM

    Configure Debug Severity on the computer that is about to be promoted using IFM media:

    • To be able to determine whether files in the SYSVOL tree are being moved in from the pre-staged folder on the local computer or are being replicated over the network from an upstream partner, set the registry value for Debug Log Severity to 4 on the computer being promoting using IFM media in the following registry subjey:
      HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParameters to 4
      Note: This has to be configured before you promote the computer to a DC using IFM.
    • Verify whether the files in the SYSVOL tree was seeded from the pre-stage folder (the restored IFM media) or replicated over the network.

To find all the files that were replicated from the initial replication partner over the wire (files that wasn’t seeded from IFM), type:

findstr /I “RcsReceivingStageFile” NtFrs_000X.log where X should be the number of the log, in case if multiple logs e.g. NtFrs_0001.log, NtFrs_0002.log etc run the command against both files.

To find all files that were sourced from the pre-staged system state backup, type:

Findstr /I “(218)” NTFRS_000X.log where X should be the number of the log, in case if multiple logs e.g. NtFrs_0001.log, NtFrs_0002.log

Posted on

ConfigMgr: Task sequence that installs many updates stops responding


Back in
2007 I was working on a fairly large System Center Configuration Manager 2007
project (an upgrade from SMS2003 with 60 000 + clients) and a Windows 2000/Windows
XP to Windows Vista upgrade, The project last for 2 entire years before it’s completion
and I decide it to be my first and last ConfigMgr project for me at least in
the Enterprise market. However one thing we never got satisfied with was the
ability to install software updates during an operating system deployment (OSD)
while we were capturing our reference images (we actually did this daily during
the development phase) – the result was very inconsistent: Sometimes it did
work like a charm, other days we could have a few updates integrated other
none.

Microsoft has now finally released a hotfix to resolve this issue and at least
it works out for me J

 

Download: Task sequence that installs many updates stops responding on a System Center
Configuration Manager 2007 SP2 client

Posted on

The place where I’ve been spending most of the time the past 12 months: Jönköping

As many of you already noticed (especially my friends) I haven’t spent much time at home in Stockholm this year cause of an Active Directory consolidation and migration project (DCMP as we refer to it internally) – anyway it’s been an extensive amount of traveling the past 12 months beyond what I’ve expected when I first signed up for this project. It has overall been an interesting project and quite some challenges with migrations/consolidations in 192 countries, 250 + DCs (logistical issues) and the list goes on here.

The picture above is the view from a conference room at a hotel in Jönköping (where I spent most of the time in this project) – In total about 60 nights out of the 120 hotel nights I’ve spent the past 12 months – Thanks goes to all the people I’ve come to know working at the hotel, In the city of Jönköping (that made my stay even more enjoyable) and of course other project members with that being said I’m finished with my part of the project and will hopefully spend more time at home again (I enjoy traveling to some extent J )

Here are some travel madness facts the past 12 months (In points) – those who ever worked with me or know me well also know that I love to collect points in various bonus programs (most of them are local in Sweden)  

Scandic Hotels:  149 200 points
SJ Prio: 105 248 points
SAS EuroBonus: 58420 points

Posted on

Upgrade Active Directory from WS03 to WS08R2 – Session is now available online

For those of you that couldn’t attend Microsoft TechDays 2011 in Sweden on site; I did a session on upgrading a Windows Server 2003 Active Directory environment to Window Server 2008 R2 with a focus on automated processes. The scripts used in this session (also available for download at this blog) were developed by the Enfo Zipper – Directory Services Team and used in a real world scenario to upgrade an enterprise customer’s forest.

The session is now available online (SV-SE, Swedish only):
Visa videon som WMV-fil

Posted on

Are you storing your AD-Integrated DNS Zones in the DNS Application Partitions (NCs)?

  1. Background

    Overview

    A partition is a data structure within Active Directory used to distinguish data for different replication purposes. Every domain controller contains the following three directory partitions: configuration, schema, and domain. A directory partition is also called the “naming context”. Domain controllers in the same forest but in different domains share the same configuration and schema data, but they do not share the same domain data.

    In Windows 2000, if the DNS server is configured to use Active Directory Integrated zones, then the DNS zone data is stored in the domain naming context (DNC) partition of Active Directory. Conversely, in Windows Server 2003, application directory partitions enable storage and replication of the DNS zones stored in the non-domain naming context (NDNC) partition of Active Directory.

    Every object created in the domain naming context, which includes DNS zones and nodes (DNS names, e.g., microsoft.com), are replicated to all the GC’s in the domain.
    By using application directory partitions to store the DNS data, essentially all DNS objects are removed from the GC. This is a significant reduction in the number of objects that are normally stored in the GC.

    Furthermore, when the DNS zone data is stored under the domain naming context of Active Directory (such as in Windows 2000), it is replicated to all DC’s in the domain irrespective of whether a DNS server is configured to run on the DC or not. This is an instance where full domain-wide replication is an over-kill.

    It would be preferable to redefine the scope of replication of the DNS zone data to only the subset of DC’s in the domain that actually run DNS.
    This can be done with domain-wide application directory partitions. Additionally, an application directory partition that is replicated to all DNS servers in the forest can be used for zones like _msdcs.<forestname> which should be visible to the entire forest.

    This is ideal because all DC’s register their DsaGuid CNAME resource record in the _msdcs.<forestname> zone.

     

    Zone Replication Options

    There are four replication options for Active Directory-integrated DNS zones. These can be selected when the zone is created or when the administrator wants to change the storage method for an existing zone. When deciding which replication option to choose, consider that the broader the replication scope, the greater the network traffic caused by replication. For example, if the administrator chooses to have Active Directory-integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network traffic than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest. The following table describes zone replication options.

    Table 1.1 Zone Replication Option Descriptions

    Storage Option

    Replication Scope
    Domain partition Active Directory domain partition for each domain in the forest. DNS zones stored in this partition are replicated to all domain controllers in the domain. This is the only Active Directory storage option for DNS zones that are replicated to domain controllers running Windows 2000 Server.
    Forest-wide DNS application directory partition DNS application directory partition for the entire forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the forest. This DNS application directory partition is created when you install the DNS Server service on the first Windows Server 2003 or later domain controller in the forest.
    Domain-wide DNS application directory partition DNS application directory partition for each domain in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the domain. For the forest root domain, this DNS application directory partition is created when you first install the DNS Server service on a Windows Server 2003 or later domain controller in the forest.

     

    For each new domain in the forest (child domain), this DNS application directory partition is created when you first install the DNS Server service on a Windows Server 2003 or later domain controller for the new domain.
    Custom DNS application directory partition DNS application directory partition for any domain controller that is enlisted in its replication scope. This type of DNS application directory partition does not exist by default and must be created. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controller that enlist in the partition.

     

    Note: DNS zones stored in application directory partitions cannot be accessed by Windows 2000 Server domain controllers.

    Forest-Wide Replication

    Given any scenario one might be able to argue that replicating DNS zone data to every DNS server in a multiple domain forest might cause excessive traffic. However, the trade off is extreme ease of administration and deployment. Especially in organizations where a dedicated DNS team may not exist, configuring DNS for Active Directory can be difficult for most. In these situations, the best solution should be the easiest solution. Therefore, using forest-wide replication for any DNS zone is considered the best option. If every zone is replicated to all DNS servers in the forest, then a customer should not need to use stub zones, secondary zones, or forwarders when configuring internal DNS resolution within the Active Directory forest.

     

    Default DNS Application Directory Partitions

    Before any of the forest or domain wide application partition replication options can be used, the DNS application directory partitions must be created within Active Directory. By default, when the DNS Server service is started, it will attempt to locate and create (if necessary) the default DNS application directory partitions (ForestDnsZones.DnsForestName and DomainDnsZones.DnsDomainName) in Active Directory.

    However, if the DNS Server service is unable to do this, an Enterprise Administrator can manually create the DNS application directory partitions as discussed below.

    Note: Enterprise Admin credentials are required to create an application directory partition.

    While it would be ideal to make a DNS server use the credentials of the administrator to create the DNS application partitions during the installation and configuration of DNS in DcPromo, it is impossible since Active Directory is not yet available until the computer is rebooted. To workaround this problem the following solution has been implemented (this is also true if the DNS service is installed on a computer that is already a DC):


    When on startup a DNS server detects that the forest- and/or domain-wide application partitions do not exist, the DNS server attempts to create the DNS application partitions.

    If it fails (which is usually the case since DNS does not have the appropriate credentials) when the first user logs in, a separate executable (waiting for the user to log in) will notify the DNS server that the user is logged in and will provide the DNS server with the credentials of the logged in user.

    Next, the DNS server will check again whether the forest- and/or domain-wide application partitions exist. If at least one of them does not exist, then DNS will attempt to create the missing application directory partitions corresponding to the domain and forest of the DNS server using the user’s credentials.

     

  2. Operation Implementation Prerequisites

    Active Directory Integrated DNS Zones

    DNS zones stored in application directory partitions must be of type Active Directory-integrated, secondary or other type of zones can’t be stored within Active Directory at, I recommends that those zones are left unchanged and stored the way they are today while Active Directory-Integrated Zones are moved to be stored in the application directory partitions (if there isn’t a specific reason to why not).

    Windows 2000 Server Domain Controllers

    DNS zones stored in application directory partitions cannot be accessed by Windows 2000 Server domain controllers, technically if a forest contains multiple domains and one or more of those domains contain at least only Windows Server 2003 DCs or later those can utilize the Domain-wide DNS application directory partition even if Windows 2000 Server domain controllers exists in other domains within the forest.

    However I recommend that the entire forest consists of Windows Server 2003 DCs or later and that all Windows 2000 Server DCs has been removed prior to the implementation of DNS application directory partitions (So shouldn’t be running Windows 2000 anyway since it’s out of support).

    Active Directory Replication Health

    I recommend that you verify the Active Directory replication health prior to the implementation, using repadmin. (repadmin /showreps /v)

     

  3. Operation Implementation Details

    The operations implementations details outlines the necessary steps required to implement and/or move DNS zones to DNS Directory Application Partitions.

     

    The operation requires Domain Admins rights and/or DNS Admins rights within the forest.

    Change replication option of existing Active Directory-Integrated Zones

    Using the DNS Manager MMC to perform the change:

    1. Open DNS.
    2. In the console tree, right-click the applicable zone, and then click Properties.
    3. On the General tab, note the current zone replication type, and then click Change.
    4. Select the following replication scope: Forest-wide DNS application directory partition.

     

    Using the command line to perform the change:

    dnscmd
    ServerName
    /ZoneChangeDirectoryPartition
    ZoneName
    NewPartitionName – The FQDN of the DNS application directory partition where the zone will be stored.

Posted on

How do I store a conditional forwarding zone in Active Directory in Windows Server 2003

This is easy in Windows Server 2008 R2 and later as you can do this simply by selecting the store this conditional forwarder in Active Directory and replicate it as follows: in the DNS Manager when you create a new conditional forwarder

  • All DNS Servers in this forest
  • All DNS Servers in this domain
  • All Domain controllers in this domain (for Windows 2000 compatibility)

If you want to store a conditional forwarder in the DS and let’s say have the replication scope set to: All DNS Servers in this forest. You can still do so but not in the DNS Manager UI, You have to use the dnscmd command line tool as follows:

  • Run the following command to create a directory integrated conditional forwarding:
    dnscmd %computername% /zoneadd <ForestRootDomain> /dsforwarder IPtoNS1 IPtoNS2 /DP /forest

     

    Note:
    If the above command failed it’s most likely because the forwarding zone already existed, either as a file based forwarding zone at one of the DCs in the forest, or already as a ds based forwarding zone. (Note a DS based forwarding can already exist in the scope of: domain, in any domain in the forest, if that’s the case either use /ZoneResetType /DP /forest or delete and re-create the forwarder)

Posted on

Upgrade Active Directory from WS03 to WS08 R2 – Sample Scripts

The sample scripts is provided “AS-IS” with no warranties

Table 1.1 Upgrade Active Directory from WS03 to WS08 R2 Sample Scripts

Name

Description

CopyLogs.VBS

This script will backup all event logs and store them in C:migdata.

GetDHCPConfig.BAT

This script will backup the DHCP database and the DHCP Server configuration and store them in C:migdata

GetDNSConfig.BAT

This script will backup none-Active Directory primary zones and store them in C:migdata

GetIASConfig.VBS

This script has a prerequisite that the iasmigreader.exe has been run (You can find this tool at your Windows Server 2008 R2 DVD at the following location: “sourcesdlmanifestsmicrosoft-windows-iasserver-migplugin” the script will move the config to C:migdata.

GetIPConfig.BAT

This script will save the current IP-config and save it in a text file stored in C:migdata

GetPrefBH.VBS

This script can be used to locate preferred bridgehead servers that can use replication issues during domain controller replacement.

GetTombstone.VBS

This script can be used to determine the current tombstone life time, if less than 180 days, we recommend to set it to 180 days.

RetireDC.cmd

This script will change the name of a demoted Windows Server 2003 domain controller to its current name __RET (retired) and configure it to acquire an IP address from DHCP.

RunDcPromo.VBS

This script is a wrapper around DCPROMO to demote a Windows Server 2003 DC, It has a feature to work around the “NETLOGN timeout bug”

SetDHCPConfig.BAT

This script will read and restore the previous backed up the DHCP database and the DHCP Server configuration from C:restore

SetDNSConfig.BAT

This script will read and the previous backed up none-Active Directory Integrated DNS Zones from C:restore

SetIASConfig.BAT

This script will read and import the previous backed up IAS config in C:restore  to NPS

unattend_demote.txt

This file contains environment specific parameters that need to be changed to reflect your environment.

The file is used to demote Windows Server 2003 DCs

unattend_first.txt

This file contains environment specific parameters that need to be changed to reflect your environment.

The file is used to promote the first Windows Server 2008 R2 DC

 

unattend_promote.txt

This file contains environment specific parameters that need to be changed to reflect your environment.

The file is sued to promote additional Windows Server 2008 R2 DCs using IFM.
Posted on

Upgrade Active Directory from WS03 to WS08 R2

First of all thanks to everyone that attended my session ” Upgrade Active Directory from WS03 to WS08 R2″ at Microsoft Tech Days 2011 in Sweden. For those of you that couldn’t attend on site I did a session on upgrading a Windows Server 2003 Active Directory environment to Window Server 2008 R2 with a focus on automated processes. The scripts used in this session (also available for download at this blog) were developed by the Enfo Zipper – Directory Services Team and used in a real world scenario to upgrade an enterprise customer’s forest.

FYI: The session will be available online later during the spring.

 

Note: The steps below including the sample scripts is provided “AS-IS” with no warranties. Some of the sample scripts have a dependence that the Windows Support Tools for Windows Server 2003 – Service Pack 2 are installed on all Domain Controllers.

 

Table 1.1 Upgrade Active Directory from WS03 to WS08 R2 Sample Scripts

 

Name

Description
CopyLogs.VBS This script will backup all event logs and store them in C:migdata.
GetDHCPConfig.BAT This script will backup the DHCP database and the DHCP Server configuration and store them in C:migdata
GetDNSConfig.BAT This script will backup none-Active Directory primary zones and store them in C:migdata
GetIASConfig.VBS This script has a prerequisite that the iasmigreader.exe has been run (You can find this tool at your Windows Server 2008 R2 DVD at the following location: “sourcesdlmanifestsmicrosoft-windows-iasserver-migplugin” the script will move the config to C:migdata.
GetIPConfig.BAT This script will save the current IP-config and save it in a text file stored in C:migdata
GetPrefBH.VBS This script can be used to locate preferred bridgehead servers that can use replication issues during domain controller replacement.
GetTombstone.VBS This script can be used to determine the current tombstone life time, if less than 180 days, we recommend to set it to 180 days.
RetireDC.cmd This script will change the name of a demoted Windows Server 2003 domain controller to its current name __RET (retired) and configure it to acquire an IP address from DHCP.
RunDcPromo.VBS This script is a wrapper around DCPROMO to demote a Windows Server 2003 DC, It has a feature to work around the “NETLOGN timeout bug”
SetDHCPConfig.BAT This script will read and restore the previous backed up the DHCP database and the DHCP Server configuration from C:restore
SetDNSConfig.BAT This script will read and the previous backed up none-Active Directory Integrated DNS Zones from C:restore
SetIASConfig.BAT This script will read and import the previous backed up IAS config in C:restore to NPS
unattend_demote.txt This file contains environment specific parameters that need to be changed to reflect your environment.
The file is used to demote Windows Server 2003 DCs
unattend_first.txt This file contains environment specific parameters that need to be changed to reflect your environment.
The file is used to promote the first Windows Server 2008 R2 DC
unattend_promote.txt This file contains environment specific parameters that need to be changed to reflect your environment.
The file is sued to promote additional Windows Server 2008 R2 DCs using IFM.

 

 

 

In addition to the presentation slide’s I will also share some additional information about compatibility between a forest/domain running Windows Server 2003 DCs compared to running Windows Server 2008 R2 and how this can effect LOB apps, services and your business.

 


Prepare a new Windows Server 2008 R2 Domain Controller

 


Operating System Configuration

 

We generally recommend that customers apply its standard Windows Server 2008 R2 Standard Edition image as long as your desired “Domain Controller Configuration” (Disk layout, Unnecessary agents are uninstalled) is applied.
Note: If you’re going to reuse the name that the previous Windows Server 2003 DC you’re replacing had, assign a temporary name.

 

The following hotfixes should be installed to prevent known issues when introducing Windows Server 2008 R2 Domain Controllers:

 


Note: The listed hotfixes has to be installed before the machine is promoted to domain controller (Or Windows Server 2008 R2 Service Pack 1).

 

Table 3.2   Required Domain Controller Hotfixes before promotion

 

Microsoft KB

Description
977158 (http://go.microsoft.com/fwlink/?LinkId=178225) Windows Server 2008 R2 Dynamic DNS updates to BIND servers log NETLOGON event 5774 with error status 9502
974639 (http://go.microsoft.com/fwlink/?LinkId=165961) Event ID 1202 logged with status 0x534 if security policy modified
2001086 (http://go.microsoft.com/fwlink/?LinkId=178226) TimeZoneKeyName registry entry name is corrupt on 64-bit upgrades
2005074 (http://go.microsoft.com/fwlink/?LinkId=185205) Event ID 1988 Logged in Directory Service Log after Schema Update
832223 (http://go.microsoft.com/fwlink/?LinkId=186576) Windows Server 2008 R2 DNS servers that use root hints are unable to resolve some DNS queries.
978055 (http://go.microsoft.com/fwlink/?LinkId=185219) Windows Server 2008 R2 domain controllers fail to authenticate DES-enabled clients.
977073 (http://go.microsoft.com/fwlink/?LinkId=186934) Digest authentication fails on a Windows XP or Windows Server 2003 member server when authenticating against a Windows Server 2008 R2 domain controller

 

We recommend that in addition to those hotfixes, the customer should ensure that the machine has reached the desired/approved patch level within the organization.

 

 

  1. Replace an existing Windows Server 2003 Domain Controller

    DHCP Service
    If the particular domain controller also acting as a DHCP Server, Logon using Domain Admin or DHCP Administrator credentials (the later also requires the logon locally right).
    Use the following steps to backup the DHCP database:

 

 

    • Click Start, click Run, type cmd in the Open box, and then click OK.

 

    • Type md C:migdata and then press enter.

 

    • Type net use X: \serverprojectshare <TBD>

 

    • Type CD scripts and press enter.

 

  • Type GetDHCPConfig.BAT -export and press enter.

    Note: While the export command runs, DHCP server is stopped and does not respond to clients seeking new leases or lease renewals. (Verify if there is another DHCP server with overlapping scopes in the same site and/or service interruption is approved)

 

DNS Service

 

If the particular domain controller also acting as a DNS Server and hosting additional none Active Directory Integrated Zones. (Active Directory Integrated Zones are stored in Active Directory and will be replicated to the destination domain controller)

 

Logon using Domain Admins or DNS Admins (the later also requires the logon locally right).Use the following steps to backup none Active Directory Integrated Zones:

 

 

    • Click Start, click Run, type cmd in the Open box, and then click OK.

 

    • Type md C:migdata and then press enter (if not already created in a previous step)

 

    • Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)

 

    • Type CD scripts and press enter.

 

  • Type GetDNSConfig.BAT and press enter.


    Note: While the export command runs, The DNS Services is stopped and started.

 

Event Logs

 

We recommend to backup the event logs of the domain controller prior to the replacement since it can help with troubleshooting.

 

 

    1. Click Start, click Run, type cmd in the Open box, and then click OK.

 

    1. Type md C:migdata and then press enter (if not already created in a previous step)

 

    1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)

 

    1. Type CD scripts and press enter.

 

  1. Type script copyLogs.vbs and press enter (make sure the logs where successfully backed up)

 

TCP/IP Settings

 

Save the TCP/IP Settings configuration so those can be applied to the destination domain controller.

 

 

    1. Click Start, click Run, type cmd in the Open box, and then click OK

 

    1. Type md C:migdata and then press enter (if not already created in a previous step)

 

    1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)

 

    1. Type CD scripts and press enter.

 

  1. Type GetIPConfig.bat and press enter

 

System State Backup

 

Ensure there is enough and health system backups before proceeding to next step.

 


Backup the captured configuration in previous step by taking the following steps:

 

 

    1. Type net use X: \serverprojectshare <TBD>

 

  1. Type xcopy C:migdata X:DCs%computername% /E and then press enter.

 

Directory Services

 

This is the final step and enters the critical point of no return where the Windows Server 2003 Domain Controller is going to be demoted to a member server and will no longer acting as a Directory Service Agent (DSA) or a replica (Replication Partner) and won’t keep an instance of the Directory Services Database.

 

Enfo Zipper recommends to run the demotion process unattended and automated to avoid mistakes and errors.

 

 

    1. Click Start, click Run, type cmd in the Open box, and then click OK.

 

    1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)

 

    1. Type CD scripts and press enter.

 

  1. Type cscript RunDCPromo.VBS . (The demotion process should now start, please wait while the Windows Server 2003 Domain Controller being demoted and restarts)

 

Decommissioning

 

Logon to the server as local administrator using the password specified in the unattended_demote.txt file above and either shutdown the server and/or disconnect it from the network. For safety reasons we recommend that the server is renamed to something else before its shutdown and that the IP-address is changed from static to dynamic.

 

 

    1. Click Start, click Run, type cmd in the Open box, and then click OK

 

    1. Type netdom renamecomputer %computername% /NewName:%computername%_retired and press enter

 

    1. Type netsh interface ip set address “Local Area Connection” dhcp and press enter.
      Note: The name “Local Area Connection” may differ from server to server.

 

  1. Type shutdown –s –t 00 and press enter.

 

 


  1. Promote a new Windows Server 2008 R2 Domain Controller

    Configure TCP/IP Settings and Names
    Logon locally to the domain controller and take the following steps in order to restore the name and TCP/IP Settings from the retired Windows Server 2003 Domain Controller that this domain controller is intend to replace:

      1. Click Start, click Run, type cmd in the Open box, and then click OK
      1. Type net use X: \serverprojectshare <TBD>
      1. Type CD scripts and press enter.
      1. Type xcopy X:DCs<NAME OF SOURCE DC> C:restore /E
      1. Type netdom renamecomputer %computername% /NewName:<NAME> and press enter (if you wish to re-use the same name)
      1. Type netsh interface ip set dns “Local Area Connection” static <IP_OF_WIN2K3DC>
        Note: The name “Local Area Connection” may differ from server to server
      1. Type netsh interface ip set dns “Local Area Connection” static <IP_OF_NEARESTBYDC>
        Note: The name “Local Area Connection” may differ from server to server
    1. Type shutdown –r –t 00

    Promote the server to a Domain Controller
    Logon locally to the domain controller and take the following steps in order to promote the server to Domain Controller, Enfo Zipper recommends to run the promotion process unattended and automated to avoid mistakes and errors.

      1. Click Start, click Run, type cmd in the Open box, and then click OK.
      1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)
    1. Type dcpromo /answer: X:scriptsunattended_first.txt and press enter. (The promotion process should now start, please wait while the Windows Server 2008 R2 Domain Controller is being promoted and restarts)

    Verify that the promotion to Doman Controller was successful
    Logon as Domain Admin to the domain controller and take the following steps in order to verify that the promotion of the Domain Controller completed successfully without errors

      1. Once logged on back, Review the DCPROMO.txt log file. Click Start, Click run and type Notepad C:WindowsDebugdcpromo.log and press enter. Search the file for the word error using notepad, ensure there were no errors, close notepad.
    1. Quickly review the DCPROMOUI.log file. Click Start, Click run and type Notepad C:WindowsDebugdcpromoui.log and press enter. Close notepad.

    DNS Service
    Enfo Zipper recommends that full replication has taken place before you proceed with the following step, in order to ensure that please run the DNSConvergeCheck script between the local domain controller and one of the domain controllers in the hub site.
    The DNSConvergeCheck script can be found at: http://go.microsoft.com/fwlink/?LinkId=135502
    If full replication has taken place, please proceed with the following commands in order to import DNS Zone data (None-Active Directory integrated Zones).

      1. Click Start, click Run, type cmd in the Open box, and then click OK
      1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)
      1. Type CD scripts and press enter.
      1. Type SetDNSConfig.BAT
    1. All DNS Zones should now successfully have been restored.

    DHCP Service
    Logon as Enterprise Admin and take the following steps to install the DHCP Server service and restore the database and settings for the Windows Server 2003 Domain Controller.

      1. Click Start, click Run, and click Administrative Tools and then Click PowerShell Modules
      1. Type Add-WindowsFeature DHCP and press enter. (if asked to/promoted to restart the server, please follow the instructions given)
      1. If a restart was required, Logon back as Enterprise Admin, Click Start, click Run, type cmd in the Open box, and then click OK
      1. Type net use X: \serverprojectshare <TBD> (if not already created in a previous step)
      1. Type CD scripts and press enter.
      1. Type sc config dhcpserver start= auto
    1. Type SetDHCPConfig.BAT -import

    Post-Operating System Configuration
    The following hotfixes should be installed to prevent known issues when introducing Windows Server 2008 R2 Domain Controllers:

    Note: The listed hotfixes has to be installed after the machine is promoted to domain controller (Or Windows Server 2008 R2 Service Pack 1)

    Table 3.6   Required Domain Controller Hotfixes after promotion

    Microsoft KB

    Description
    978387 (http://go.microsoft.com/fwlink/?LinkId=184915): Dcdiag fails with error code 0x621
    978277 (http://go.microsoft.com/fwlink/?LinkId=184911): The specified account does not exist
    978516 (http://go.microsoft.com/fwlink/?LinkId=185190) Significant delays when you read the same set of files several times
    978837 (http://go.microsoft.com/fwlink/?LinkId=185191) Group Policy Management Editor window crashes when you apply some changes for NRPT policy settings

    Disable EDNS
    Disable EDNS to avoid issues with global DNS servers that doesn’t support EDNS, (Not needed if forwarders is configured to handle external DNS queries outside the forest and to the internet)

      1. Click Start, click Run, type cmd in the Open box, and then click OK
    1. Type dnscmd /config /EnableEDNSProbes 0 and press enter.

    Configure Kerberos supported encryption types
    Note this step is only required if the domain contains service accounts and/or computer accounts that are configured to use DES-only encryption.

      1. In the Group Policy Management Console (GPMC), locate the following location: Computer Configuration Windows Settings Security Settings Local Policies Security Options
      1. Click to select the Network security: Configure encryption types allowed for Kerberos option.
      1. Click to select Define these policy settings and all the six check boxes for the encryption types
        .
    1. Click OK. Close the GPMC.

    Note: The policy sets the SupportedEncryptionTypes registry entry to a value of 0x7FFFFFFF. The SupportedEncryptionTypes registry entry is at the following location:
    HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemKerberosparameters

Posted on

Guidelines for choosing the most appropriate store for directory information

Here are some guidelines to follow to choose the most appropriate store for placing directory information (usually requested as a schema extension, with additions of attributes and/or classes)

If a schema change is required for an enterprise-wide application, such as Exchange Server that has a major integration (effect’s most objects in the forest) and required interaction with security principals the change probably has to take place in the main forest. However, if the schema change is required for an application that a small population of the organization will use, You should determine whether deploying a such global change to satisfy the needs of this small population of the organization is warranted, in addition you should analyze whether the schema change is a long-term or short-term requirement, also if the data to be hosted in the directory is frequently changing, or is already hosted in a different format with in the forest,

You should consider an alternative directory store, such as a specific application directory using Active Directory Lightweight Directory Services (AD LDS) to support applications that depend on schema extensions that are not desirable in the AD DS directory— for one or more reasons such as schema extensions that only are useful to a single application or only required on a short-term basis.

The following table supports the process to determine the most appropriate directory information store for a particular application/schema extension.

 

Description

Points
A small population of the organization will benefit/use the schema extension, less than 40% 2 points
Schema extension are deployed on short-term basis, application/system lifecycle equal to/or less than 2 years 2 points
Schema extension will host data already available in AD DS 8 points
Schema extension will store more than 256k on a single object 3 points
Schema extension will introduce none-optimizeable LDAP queries 4 points
Schema extension OIDs can’t be verified 12 points

If the schema extension qualifies for more than 3 points above, I advised to choose Active Directory Lightweight Directory Services (AD LDS) as the directory information store over Active Directory Domain Services (AD DS).

Posted on

Identity Management Strategy Ideas

I recommend most customers to implement an identity Life-Cycle Management process to provision and de-provision identities where those identities and it’s associated data on a best effor will automatically flow in from an authoritative data source with the ability for approved managers to use an manual process to fill in missing data (there is usally no way to fully automate all scenarios in large enterprises) in existing identities or request new ones outside the automated flow. I also believes that providing Self-Service into the flow, so that end-users can complement any missing data will enhance the overall identity quality. 

 

Here is some general ideas and recommendations :

 

·        FTE – Full Time Employees. On best effort HR-driven provision and de-provision with the ability for approved managers to request an identity before it becomes available in the HR system, once the identity appear in the HR system it will merge with the one requested on forehand by the manager.

FTE’s should be able to some extent modify/correct the data about their own identity(s) using a Self-Service Portal, such as adding a cell-phone number. Security mechanisms, compliance management and approved managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be HR-driven and identities should be archived up on unemployment so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).

 

·        Vendors and Contractors. On best effort Sponsor-driven provisioning and de-provisioning where the sponsor (the person responsible for contracting the vendor/contractor) approves and provide a central repository with required information for external users, the end date for the contract should also be defined.

Vendors and Contractors should have limited access to modify/correct the data about their own identity(s) using a Self-Service Portal, such as perform a reset of their passwords, Security mechanisms, compliance management and the sponsor should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be Sponsor-driven and/or expire date-driven, identities should be archived so that tracking possibilities remain and the sponsor should be able to access/transfer remaining work associated with the identity(s).
 

 

·        Temporary Accounts. Temporary accounts should be provisioned by approved managers which are required to provide a central repository with required information about the identity that will gain temporary access, defining an end date for the temporary account should be required.

Temporary Accounts should not have access to modify data using a Self-Service Portal, Security mechanisms, Compliance management and the managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be expire date-driven, identities should be archived so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).

 

 

·        Administrative Accounts. Administrative Accounts Administrative Accounts should be driven by an already existing identity that controls provisioning and de-provisioning where an approved manager after that the identity has been validated either by a board or/and in conjunction with security responsibilities approves and provide a central repository with required information for an administrative account.

Administrative Accounts should have limited access to modify/correct the data about their own identity(s) using a Self-Service Portal, such as perform a reset of their passwords, Security mechanisms, compliance management and approved managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be driven by an already existing (regular) identity and/or expire date-driven, identities should be archived so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).