ADMX files, where to put them, and you – take 2

A few years ago, I wrote a blog on the storage location of ADMX files. For Group Policy, these files are crucial, as they define the settings you see in the Group Policy Editor, and by extension, they describe the registry settings which need to be managed on each client workstation to which a policy is applied.

(Contrary to popular belief, the Group Policy Engine on a client does *not* need to refer to these files to actually apply Group Policy. The Group Policy Editor parses the file and stores the specific registry modifications in the appropriate location in the SYSVOL folder structure. The editor does, however, require access to all the proper ADMX files to allow an administrator to make policy changes)

The ADMX format was introduced in Windows Server 2008 and Windows Vista and is XML-based, unlike the previous ADM file syntax of Windows Server 2003, which was a custom syntax which proved challenging at times.

In my earlier post, I specified that the best location to store these files is %systemroot%\PolicyDefinitions on each of your DCs. This was in response to a specific problem I had at a customer with a new, single, standalone Domain Controller.

However, on much larger networks, this advice is not something I would endorse. By storing the policies in the PolicyDefinitions container on each DC, the ADMX files will only be available in the Group Policy Editor on that particular Domain Controller. If you want to use Group Policy Management Console from a workstation, another DC or a member server, then you are going to have many settings which have no policy definition, so you will be unable to manage them. With products like Server Core (a particular focus of Windows Server 8 Beta), managing Group Policy from the DC’s desktop is no longer a recommended or particular routine operation. Similarly, managing a DC directly from its desktop for such routine changes is not a best practice – delegating control over Group Policy and making the changes on a workstation would be a better choice. So, we need a better way of sharing the ADMX files across the entire LAN to ensure they roam to any machine where policy may be set.

Fortunately, Microsoft already have a solution. It’s known as the Central Store. Essentially, this is a PolicyDefinitions folder within the SYSVOL folder hierarchy which you already know about. By placing the ADMX files in this directory, they are replicated to every DC in the domain; by extension, the ADMX-aware Group Policy Management Console in Windows Vista, Windows 7, Windows Server 2008 and R2 can check this folder as an additional source of ADMX files, and will report them accordingly when setting your policies.

By default, the folder is not created. Whether you are a single DC or several thousand, I would strongly recommend you create a Central Store and start using it for all your ADMX file storage. It really does work well.

More information and detailed procedures are available from Microsoft Support.

Exchange Server password expiry handling on iPad/iOS 5

Overnight, the password for my Exchange account expired, as would be expected in line with my security policy.

Unfortunately, it would appear there is a bug in iOS 5′s handling of this situation. My iPad (running iOS 5.0.1) had many, many “incorrect password” prompts when I picked it up to use it this morning. There were so many that I was about to concede that the iPad as unusable until I found a computer to change my password on, as the password was yet to be set to a new value.

I would usually change my password directly from the iPad, by logging in to OWA, where I have enabled the ability to change a password when it has expired.

After some time of pressing “Cancel”, I was finally relinquished from the grasp of this prompt and was able to proceed to use the iPad normally.

It would appear to me that the number of prompts would be equal to either the number of Fetch attempts since the password expired and/or the number of occasions the iPad has tried to open a session for push delivery from the server. Of course, the iPad would have failed on every occasion, and it would appear it is being extremely verbose by displaying each and every failure.

Either way, the code should detect an incorrect password and show the “Incorrect Password” pop-up once only, as was the behaviour I experienced on iOS 4. If I choose to dismiss that message, I should not be repeatedly prompted with the same alert. As a tech savvy user, I repeatedly hit “Cancel”, but many of the users I deals with on a daily basis would try this a couple of times and then assume their iPad was unusable and not continue for fear of “breaking” something.

It seems I am not the first to come across this issue, but I will add my voice to those who hope this issue is resolved in a future iOS release.

For Exchange and AD admins, be aware this issue could potentially lead to lockout situations, dependent on your security policies.

Windows XP Favourites Redirection – ADMX files

One of the major disadvantages of still running XP in production is its lack of Internet Explorer Favourites directory redirection. If your users frequently roam between computers, the usual workaround is to enable Roaming Profiles to have the favourites roam with them. This usually works, until Windows Vista or 7 is introduced into the environment.

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2″ appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.

Demystifying the Active Directory FSMO roles

If you’ve spent any time administering Active Directory, you’ve probably come across the concept of Flexible Single Master Operations (FSMO) roles. Their introduction is arguably one of the most important but misunderstood changes to Active Directory in the last ten years.

Take a trip down memory lane

In the days of Windows NT, one may recall the Primary Domain Controller (PDC) and Backup Domain Controller (BDC) concept. The directory was structured such that every DC, whether a PDC or a BDC, had a copy of the directory database, but only the PDC could make changes to that database. The model was inefficient, negatively impacted growth and desperately needed improving if the product had any chance of surviving.

Enter Windows 2000. The Directory Service went through one of its largest scale rebuilds to date. Replication and management was significantly improved and the concept of having a multi-master directory was introduced. Although this design has been tweaked over the years, fundamentally, it has remained the same through the versions – because it works. Any DC anywhere in the domain can execute virtually any update to the directory. This scales beautifully, even on large, geographically dispersed networks with many thousands of users.

However, notice I said virtually any change. Since a change can take effect at any DC, there is the possibility that a conflicting change will be made in two locations concurrently – or before replication can occur. Active Directory must ensure these situations are accounted for. In most cases, it applies its complex Multimaster Conflict Resolution Policy, which essentially says the last change wins. However, there are several procedures which simply cannot conflict; these procedures are assigned to one of the five FSMO roles, which go on to be delegated to one or more Domain Controllers.

What are the FSMO roles?

There are nominally five roles present in the directory which reside on DCs nominated specifically by the Administrator to perform these tasks. All the roles are very important and constitute a single point of failure in all Active Directory enterprises. If you have a complex topology with more than one domain, some roles are domain-specific, so you can expect to have duplicates of some roles in every domain in the enterprise.

• The Domain Naming Master exists once per forest – in the forest root domain – and is rarely used. It is responsible for processing the addition of new child domains, application partitions and external cross-references to the enterprise. Since the name of a child domain or application partition cannot be duplicated (it would conflict in DNS, let alone send Active Directory around the twist), the DC holding this role is the only DC with the ability to process all additions of this kind in the forest.
• Infrastructure Master: If a user from a foreign domain within the same forest is added as a member of a compatible group in another domain, the DCs in the group’s domain must have some information about that user in its local database in order to update the member attribute of the group. To do this, it adds a special record to its database called a phantom, which contains only the foreign user’s security identifier (SID), globally unique identifier (GUID) and their distinguished name (DN). Like all objects in the database, this record is given a distinguished name tag, or DNT, an internal reference used solely in the low-level Active Directory database layer. In doing this, the directory service is able to add that user as a member of the group by referring to the phantom’s DNT, just like it would refer to a user’s own DNT if you added a user from the group’s own domain to the group. You might think of this like using a primary key in a relational database to refer to objects across tables, but not exactly, as Active Directory’s database is by no means any sort of RDBMS.

  That’s very clever, but what if something about the source user in their original domain changes? If the user is renamed, moved or deleted, the phantom in the group domain DC databases would lose its referential integrity with the source domain. This is a situation the infrastructure master aims to avoid. On a periodic basis (by default, every 2 days), the infrastructure master – an FSMO role present in every domain – compares its local database to a Global Catalog (GC) server to determine whether any changes have been made to the objects the phantoms were created to represent. A GC contains a partial replica of all objects in the forest, so replication means any GC would already know about this updated data. The phantom is then updated with new values or deleted from the domain’s database if the object has been removed from its source domain.
  
  In a multi-domain forest, you must either locate this role on a Domain Controller which is not a Global Catalog or, if you must locate the role on a GC, ensure all DCs in that particular domain are GCs. A GC will never create phantoms because it already knows about users from other domains. If the infrastructure master is a GC, there will never be any phantoms in its local database to compare with the global catalog data, so no updates will be made, but other non-GC DCs in the domain would gradually become outdated. If all DCs in the domain are GCs, or you only have a single-domain forest, every DC knows enough about the security principal that it does not need to create a phantom, so this role is essentially redundant.
  

• Schema Master: As the name suggests, this role is the Master of the Schema, the information which contains the formal definitions of how Active Directory stores objects, what attributes are available on those objects and so on. This role exists once per forest, on a DC in the forest root domain. Any updates to the Schema must be tightly controlled, so one DC delegated as the Schema Master performs all such changes to the database. Schema updates are then replicated to other DCs on the network by standard Active Directory replication.

So far, three of the five roles have been covered. Those above are those I would consider the least critical FSMO roles in the forest. If you lose the DC delegated one or more of these roles, it’s no big deal — it may prevent a network administrator taking an action, but it will not impact the usability of the network. Losing the Domain Naming Master or Schema Master would create problems in regard to creating child domains or running schema updates, but these generally occur very rarely and checking this Operations master DC is up would be part of the planned engineering works. Similarly, losing the Infrastructure Master may cause integrity issues in the database, but given that it only runs its scan every two days in the first place, a day or two of outage will not generally cause an issue.

• RID Master: This role is one of the two which are important to the daily operation of Active Directory. Under the glossy GUI of Windows, security principals are identified and differentiated by use of two values – a Security Identifier (SID) and a Globally Unique Identifier (GUID).A SID is an alphanumeric string which is unique throughout a forest. The SID is the actual value used internally by Windows to identify users and grant access to resources using Discretionary Access Control Lists (DACLs), for example, via the ‘Security’ tab on a file or directory. Have you ever deleted a user, recreated her, then wondered why she cannot access the same files and folders, despite having the same username? The new account would have a new SID and is therefore considered an entirely different security principal to the system.Contrary to popular belief, the username, distinguished name or full name of a user are not internal tracking mechanisms within Windows as all these values could change.The standard make up of an SID might be as follows (this SID is purely random): S-1-5-21-789336058-1123561945-725345543-10823.The nature and formation of an SID is beyond the scope of this article, but it is the very last octet (in this instance, 10823) we are interested in. This figure represents a Relative Identifier (RID), an incremental value which actually makes the SIDs unique within a domain, ensuring no two users conflict in the database. When a security principal (user, computer, group etc.) is created, the domain SID (in this instance S-1-5-21-789336058-1123561945-725345543) has the next available RID appended to the end.Each Domain Controller is initially allocated a pool of 500 RIDs. As security principals are created, RIDs are used up. The allocation of RIDs to DCs is a task delegated in the RID Master FSMO role to one DC in a domain. Placing the operation in an FSMO role ensures no DC obtains a duplicate RID pool, which would eventually lead to conflicts in SID values and a major problem in terms of SID-uniqueness within the domain.
• PDC Emulator is the most complicated and least understood role, for it runs a diverse range of critical tasks. It is a domain-specific role, so exists in the forest root domain and every child domain. Its original conception was for backwards compatibility with legacy systems, such as Windows NT BDCs. However, the role is also responsible for keeping the domain time in sync, given that the DC holding this role in the forest root domain is the most authoritative time source in the forest. Password changes and account lockouts are immediately processed at the PDC Emulator for a domain, to ensure such changes do not prevent a user logging on as a result of multi-master replication delays, such as across Active Directory sites.It should be noted that the PDC Emulator does not act in the same fashion as a PDC on a Windows NT network. Cast your eye back to the top of this article and note the section regarding a multi-master directory — for multi-master aware applications, most updates can be made at any DC on the network. However, if an application (or Operating System) is not multi-master aware, the PDC Emulator acts as if it were the PDC on the Windows NT network. One of these older applications would most probably single out the PDC Emulator and write all its changes there.

The latter two roles are much more crucial to the daily operation of the network and could very quickly become a limiting factor in its growth, usability or even the logon process if the DC(s) holding the roles are offline for any period of time. If the RID Master is lost, impact will only be felt by the Network Administrator if a DC depletes its pool of RIDs. On busy networks, this could potentially occur in a matter of days through the creation of new security principals. However, loss of the PDC Emulator could directly affect your users — you’d better have a substantial help desk ready for a spike in call volume if this DC is down for an extended period of time. For example, with the most authoritative source of time unavailable, time skew could eventually occur between DCs and computers in the enterprise and/or domain, lending itself to Kerberos authentication errors and ultimately, failed logons. While it would not be an immediate issue to take this server offline (provided you do not have any legacy applications), this would be the role I would be most concerned about in the event of a DC failure.

Conclusion

If you are still reading, well done! This article covers several aspects of Active Directory in detail, including low-level database processes unseen at the surface – particularly via the GUI. However, FSMO roles are a crucial component of your deployment — having an understanding of the underpinning concepts will help with their placement, deployment and high availability concerns within your enterprise.

Active Directory Diagnostic Logging

Active Directory MVP Brian Desmond just posted a great blog entry which describes the generic registry settings he makes on a new Domain Controller.

The ones which are particularly important for any Domain Admin are the diagnostic logging settings for the Active Directory services. Any dedicated admin should keep a watchful eye on their DCs and know exactly what is going on with them. Making effective use of Diagnostic Logging is one of the best ways you can do this. By default, only errors are logged by Active Directory, something which isn’t useful for day-to-day monitoring and administration.

In the above linked blog post, Brian adds a line to ensure Active Directory logs the white space available in the database (also known as ‘the DIT file’ – from NTDS.DIT) after Garbage Collection does its work and removes objects permanently from the database. For any Exchange Server admin, you will be familiar with the concept of white space in the databases. The Active Directory DIT file uses the ESE storage engine in the same way as Exchange does, meaning white space is also left in the Active Directory database as objects are removed.

There are a few Microsoft support sites which explain all the diagnostic logging settings (there are several) in more detail, how to enable each setting and set the logging level. I’d suggest you take a look at this one to begin with: http://technet.microsoft.com/en-us/library/cc961809.aspx.

Happy Diagnostic Logging!

Configuring Windows Time for Active Directory

I’ve had a few requests recently from people who were confused regarding how to configure time in their Active Directory domains – and some were playing with settings on servers and workstations to try to make things work. In this article, I’ll briefly explain how the time service works in Active Directory networks and general information on how you should go about configuring it.

For anyone not aware, all machines in an Active Directory environment automatically find a time server to sync time with. Workstations use their authenticating Domain Controller, and the DCs sync with the server holding the PDC Emulator FSMO role. In a multi-domain forest, the PDC Emulator in each child domain synchronises with a DC or the PDCe in the forest root domain. To ensure the time remains reliable across the forest, only the PDC Emulator in the forest root domain should ever sync with an external time source – this leads to only one source of time being used across the forest. The Windows Time Service blog have a great post entitled Keeping the domain on time which explains this in more detail, including a great graphic.

The Windows Time Settings

You can find the settings for the Time Service in the registry, under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. The most important value to note is the ‘Type’ string – on any domain machine other than the PDC Emulator in the forest root, this should be set to NT5DS. That name isn’t particularly descriptive; if it is set, it means the machine is finding a time server in the Active Directory hierarchy.

If it isn’t set to that, you should think about resetting the time service on that machine. To do that, run a Command Prompt as an Administrator and execute the following commands:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Check the registry again, and the Type should now be in domain sync mode (NT5DS).

Sometimes, you may find an NTPServer key in the registry despite the Type being set to NT5DS. NT5DS doesn’t use an NTP Server, so what gives? This setting is simply left over from prior to the machine being joined to the domain, when it was in a workgroup. Provided the Type value is set correctly, the NTPServer entry can be completely ignored or even deleted. Running the above commands on a domain-joined machine will delete it automatically.

The Group Policy Settings

There are also a number of Group Policy settings for the time service. These can be found in Computer Configuration\Administrative Templates\System\Windows Time Service.

I do not encourage you to change these settings; if you have done so, you probably want to revert the policies to ‘Not Configured’. There are reasons why you may make the odd change, but in general, no changes are required and you can actually break the time sync if you do make them.

If you are interested in reading further about what they do, the Windows Time Service blog has another great page going through them: Group Policy Settings Explained.

The Forest Root PDC Emulator Settings

After a bit of a configuration reset, all your DCs, member servers and workstations should now be set to sync from the domain hierarchy. But what about the PDC Emulator in the forest root?

The fact of the matter is the PDCe doesn’t actually need to synchronise with anything. It automatically designates itself the most reliable time server in the domain and it can run quite happily like that, without ever talking to an external time server. My earlier blog post entitled Time: Reliable or accurate? describes why.

However, to have an easy life and keep your users from complaining, it is almost always a good idea to have some form of external time sync on the forest root PDC Emulator. There are a number of ways to do this – for example, an external hardware clock which syncs with GPS. However, the most common (and cheapest – free) solution is synchronising with another NTP server on the Internet. I often use the servers closest to me which participate in possibly the largest time service, the NTP Project (list of time servers). Be aware that if you are bound by SLAs (my company certainly is), by its very nature, the NTP project most probably isn’t the resource for you.

To configure the time sync on the PDCe, you need to execute the following commands. I’d strongly suggest you get a level playing field by resetting the time service using the instructions above before you start.

w32tm /config /manualpeerlist:”uk.pool.ntp.org,0×8 europe.pool.ntp.org,0×8″ /syncfromflags:MANUAL /reliable:yes /update

What’s that command doing?

That command is a rather hefty command, so you may like to know exactly what it is doing to your server. All the changes are taking place in the registry at the key I posted above; using the w32tm tool to make the configuration changes is simply much easier than doing it manually yourself.

/config causes the tool to enter configuration mode. There are a number of other modes it supports which you can find by running w32tm /?.

/manualpeerlist allows you to specify the NTP server or servers you wish to synchronise time with. In this instance, each server’s DNS name or IP address should have a comma followed by the string 0×8. This instructs Windows to send requests to this external server in client mode. If you enter multiple servers, which I suggest, put the servers in quotation marks and separate each entry with a space. The value you specify here is written back to the NTPServer value in the time service’s registry key.

/syncfromflags tells the time service where it should sync time from. You can specify two entries for this – either DOMHIER or MANUAL. The former causes the time service to synchronise with the Domain Hierarchy (sets NT5DS in the Type key in the registry) whereas the latter tells the time service to sync with the server(s) you specified in the Manual Peer List. MANUAL sets Type to NTP.

/reliable sets the server to be a reliable source of time for the domain. Strictly it isn’t required, because the PDC Emulator in the forest root is always the most reliable time server, but I like to include it anyway.

Finally, /update notifies the time service the values have changed, so the new settings are used with immediate effect. If this isn’t included, the registry is updated but the new values will only be used by the time service when its service or the server itself is restarted.

After you’ve run that command, you might want to take a look in the registry to see what changes have been made, and whether they are as you expected.

Check Time Synchronisation

You may be intrigued to know whether the time sync is working correctly. You can do this in one of two ways.

The safest is to wait for a scheduled time sync to take place, or restart the machine. Either will trigger Event ID 35 to be logged in the System log. This event’s description shows the time server the machine is synchronising with. This will be logged on both the PDC Emulator and all DCs, member servers and workstations. You can check for this on member machines to ensure a DC in the domain hierarchy is being found and used correctly – and to ensure your custom NTP servers configured on the PDC Emulator are being used as intended.

Alternatively, putting your cowboy hat on, you can force a time synchronisation. Set the time a minute or two out from what it should be, then return to the command prompt and run w32tm /resync /rediscover. After a few moments, the above event should be logged, and a healthy time service should cause the time on the system to be set back to normal.

As a note, no time synchronisation will take place if the difference between the current system time and the new time provided by the time server is too great. A minute or two is fine, but I would not set the difference to be any more than that. The system checks this difference at each sync, and will reject the new time provided by the time server if it is too large.

Conclusion

You should now have an understanding of how the time service works and where it stores its settings in the registry. While time isn’t one of the most fun services an Active Directory administrator will work with, it is important you ensure the forest stays in sync if you want to avoid major problems with time skew, Kerberos and Active Directory in general.

Time: Reliable or Accurate?

The Windows Time service was initially created with the intention of maintaining loose synchronisation of time between all the nodes on a network. This is particularly important in Active Directory domains, where Kerberos Authentication requires two machines to have a difference of no more than 5 minutes (by default) between the client and server before a secure session can be set up.

When it comes to synchronising time, there are two words which are important but often cause confusion: Reliable and Accurate.

Reliable time is the most important in Active Directory, and is what Kerberos needs to work correctly.

For time to be reliable, the two machines’ time needs to be as close as possible to each other. For Kerberos, time readings within 5 minutes of each other will suffice as being designated reliable.

However, accurate time is something nice Domain Admins seem to be generous with giving to their users. They don’t have to. The most accurate time is time which exactly matches real worldwide GMT time, as tracked by the world’s atomic clocks.

Example

Suppose the real time now is 02:00:00.

If I set the time on both my Domain Controller and workstation to 18:00:00, nothing will break. Why? The time is still reliable – there is no difference in time between the two machines. However, the time is not accurate, and users will quickly complain the clocks on their machines are incorrect. Accurate time is little more than a nice feature; accurate time is by no means required for Windows to function correctly.

Conclusion

What I hope you have obtained from this article is that having an accurate clock on a workstation is not necessary. You could run your machines several hours out from normal time, but provided the time remains reliable, you won’t notice a problem.

Active Directory: PDCs and BDCs

On a number of forum threads I participated in recently, there was some confusion over the terms ‘PDC’ and ‘BDC’, and how they apply to a modern Active Directory domain.

In short, they don’t apply any more. The only exception to that rule is if you still operate a Windows NT-based domain.

Some History

On a Windows NT domain, one Domain Controller was designated the Primary Domain Controller (PDC). You were able to promote (although it was optional) one or more servers as Backup Domain Controllers (BDCs), which offer resilience by taking over the role of the PDC if it fails.

The process was very similar to today’s Active/Passive clusters in Windows Enterprise Server Failover Clustering. The PDC (Active node) was where all the domain update actions took place. These changes were later replicated to the BDCs (Passive nodes), to maintain an up-to-date Active Directory database. If the Active node/PDC failed, one of the BDCs would become the PDC and directory operations would continue while the problem was resolved.

How has this changed?

As I mentioned previously, this concept no longer exists – and hasn’t since Windows 2000. For the Windows 2000 release, Active Directory went through a major redesign.

The Domain Controllers in a Windows 2000, 2003 and 2008 domain now support multi-master replication. This means read and write operations can take place on any DC – changes don’t need to go through the PDC. Each change is later replicated between the other DCs in the domain.

This change meant more flexible environments spread across multiple sites, maybe in different countries or continents, could easily be created and managed.

What is the PDC Emulator (PDCe)?

So, that said, I hear you ask “So what is the PDC Emulator? Why do I still see references to the ‘PDC’ on my domain?”.

Active Directory has 5 FSMO roles (look out for a blog post from me soon about this topic). FSMO stands for Flexible Single Master Operation. Although most standard Active Directory actions can take place on any DC (the multi-master idea), some can only take place on one DC (single-master) to ensure no conflicts occur.

The PDCe role exists largely for backwards compatibility for legacy Operating Systems. They are designed to find the Windows NT PDC on a domain network, so designating a DC as the PDCe means these older Operating Systems continue to work correctly.

The PDCe could also be considered the most important Domain Controller in the domain – although you can survive without this DC if necessary. A number of tasks are assigned to the PDCe which help maintain the domain:

• The PDCe is the most reliable time server in the domain, which all workstations and servers (either directly or indirectly) synchronise their time to. There’s a good post on this on the W32time blog.
• Through PDC chaining, the PDCe has the final say in whether an account is locked out or if a user’s password was correct. Group Policy MVP Florian has a great blog post on this.
• If you are running in Windows 2000 Mixed Mode and still have Windows NT BDCs, the PDCe acts as the PDC for the Windows NT machines, and manages replication with them

Conclusion

Hopefully you now have a much better understanding of the terms PDC, BDC and PDC Emulator, and how they apply to your environment. Multi-master replication has transformed Active Directory; almost every change can be made on any DC anywhere on your network, rather than going through the PDC.

However, the PDC Emulator is still an important Domain Controller. While it is not as critical as in Windows NT days and your domain can survive without it, I suggest you keep the PDCe online and accessible from the other DCs as much as possible.

Where do I put my ADMX files?

Note (4th May 2012): As this post proves to be ever popular, I have updated it to account for new developments and to provide a more general method of storing your ADMX files, especially on large networks. Please check out the new post: ADMX files, where to put them, and you – take 2.

ADMX files are the new form of ADM files, the format which defines what Group Policy settings set what registry changes when they are applied. With Microsoft’s move to XML-based file formats and alongside their release of the new Office 2007 file extensions (DOCX, XLSX, PPTX etc.) the ADM format was also upgraded to ADMX.

People familiar with ADM files would remember that in order to have Group Policy Editor read the ADM file and add the settings to the policy, they would need to Add the template. However, for ADMX files, you cannot add them via the Add/Remove Template wizard in Group Policy Editor, because they do not appear as an option to add.

Windows reads the ADMX files on the system from a pre-defined location, and that location is the only location on the system where you should place the ADMX files. It is %systemroot%\PolicyDefinitions, where %systemroot% is normally C:\WINDOWS.

Any ADML files you receive with the ADMX files should be placed into a subfolder within PolicyDefinitions, named after their MUI ID. For example, a en-US ADML file would be placed into the directory %systemroot%\PolicyDefinitions\en-US.

Once you have stored your ADMX files in their respective locations, it is simply a matter of restarting Group Policy Management Console for the files to appear in the Group Policy Editor.

It should be noted that any form of ADM/ADMX file only needs to be present on the machine where the policies are edited from. It does not need to be present on every machine on the network. The ADMX files simply link the GUI of the GPO Editor with the appropriate registry settings to make; the registry settings are simply stored and processed at each client where the GPO applies.

Exchange 2007 access to all mailboxes for Administrator

Deploying Exchange 2007 can have its problems at the best of times. The separation of Exchange management from the Active Directory tools also has a knock-on effect when it comes to granting Exchange-related permissions en masse. This seemingly easy task is now proving to be a minefield.

So, how do you grant an Administrator access to all the mailboxes for an Exchange 2007 Mailbox Database?

Remove the Default Permissions

Before you start, you need to remove the default permissions at the Exchange Organization Level. These apply to all mailboxes in the organization and specifically deny any administrative-type user the Send-As and Receive-As permissions. This may cause confusion later, so it is best to remove them.

The user accounts and groups which are denied the ‘Receive-As’ permission at the organization level are:

• DOMAIN\Administrator
• DOMAIN\Domain Admins
• DOMAIN\Enterprise Admins
• DOMAIN\Exchange Organization Administrators

In order to remove the Deny entry for all the above users, the following command should be used:

Get-OrganizationConfig | Remove-ADPermission -User “DOMAIN\Administrator” -AccessRights ExtendedRight -ExtendedRights Receive-As -Deny

Replace DOMAIN\Administrator with the other entries in the above list to remove the permission for those accounts too.

The Commands

Having removed the default permissions, you can now set about implementing the permissions needed. Prior to discussing the actul Powershell commands to use, it is important that you understand the different types of permission which can be granted:

• FullAccess Mailbox Permission. This can only be granted at the individual mailbox level to a user or group of users; it allows the designated users the ability to access the mailbox via Outlook or the new feature to open another user’s mailbox in Outlook Web Access.This permission is granted directly on the mailbox using the cmdlet Add-MailboxPermission. An example might be Add-MailboxPermission -Identity JDoe -User MSmith -AccessRights FullAccess where MSmith is being granted the ability to access JDoe’s mailbox.This permission can also be granted via the Exchange Management Console. Selecting a Mailbox in Recipient view adds an option Manage Full Access Permission to the actions pane, where this permission can be managed in a similar fashion.The problem with granting permissions in this fashion is it has to be done on an individual mailbox basis. For granting permissions en masse, it would defeat the principles of granting permissions due to the administrative overhead of maintaining the ACLs. Instead, permissions should be granted on a common parent object and allowed to inherit to the child objects, in this case, the mailboxes.
• Receive As Active Directory permission. This permission can be set either at the mailbox level, or at a higher level in the Active Directory tree. It has the same effect as Full Mailbox Access, with the difference that it can be set at the store or storage group level, and therefore will be inherited down by all decendent mailboxes.Generic Active Directory permissions related to Active Directory objects are granted and modified at the Management Shell using Add-ADPermission. This cmdlet expects the -Identity parameter to be a full Active Directory path – I believe a Distinguished Name is expected. It is, therefore, much easier to pipe this path from the result of a previous command, particularly when handling some of the more complicated Exchange objects with complex DNs. For example, to grant these permissions at the store level (the store being an Active Directory object), I could use: Get-MailboxDatabase -Identity “My Database” | Add-ADPermission -User “DOMAIN\Group of Users” -AccessRights ExtendedRight -ExtendedRights Receive-As
  

The problem with granting Receive As permissions is while Outlook will obey them and happily display a mailbox where the Receive As permission is inherited, the new feature of Outlook Web Access which allows other mailboxes to be opened does not. For the OWA feature to work, the user must be granted explicit Full Mailbox access on an individual mailbox basis, to every mailbox they need to access.

My Approach

To achieve the ultimate objective of allowing Domain Admins to access a mailbox, either from Outlook or OWA, I chose to use several commands.

I first granted Domain Admins ‘Receive-As’ access at the store level using the command I described above. Via Outlook, these permissions would allow any Domain Admin to open these mailboxes as additional mailboxes.

To counteract the OWA restriction, I had to grant the Full Access permission across every mailbox. While this is very messy to maintain, it is currently the only option. Furthermore, as new mailboxes will not have the permission set by default, I use a Scheduled Task with a small PowerShell script, to set the permissions for every mailbox once per day.

My PowerShell script (.ps1 file) consists of the following:

# Matt’s Powershell Script (see tigermatt.wordpress.com) to add Full Mailbox permissions to all mailboxes in the Exchange organization
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue
$userAccounts = get-mailbox -resultsize unlimited
ForEach ($user in $userAccounts)
{
add-MailboxPermission -identity $user -user “Domain Admins” -AccessRights FullAccess
}

Via Task Scheduler (Windows Server 2008), you can launch the script by specifying powershell.exe as the application, and “& ‘C:\path\to\script.ps1′” as the parameter. Note the double-quote followed by single-quote, and the requirement to close both quotes at the end of the command.

On the basis defined by your Scheduled Task configuration (I would suggest the task runs daily during the night, when the load on the server is low), the script will enumerate all mailboxes in the Exchange Organization, adding the required Full Access permission to the Domain Admins group.

This concludes my entry on granting various permissions in Exchange using Powershell. I hope I have cleared up some concerns regarding the differences between adding Mailbox Permissions and adding Active Directory permissions, and that this helps you.