January, 2009

Hey, Chris here. I recently had a case where the customer wanted to determine what Schema Extensions have been made to their schema. I decided to do this via an excellent utility called the AD DS/LDS Schema Analyzer. The AD DS/LDS Schema Analyzer is a tool that is part of Active Directory Lightweight Domain Services. The AD DS/LDS Schema Analyzer is intended to be used to migrated Active Directory Schema’s to ADAM. However, it can also be used to compare to AD Schemas.

The process of using the AD DS/LDS Schema Analyzer to determine what schema changes have been made in your environment, does take a little work. Below is the whole process.

1. Build a test environment, which matches your Active Directory Environment, this will be used for your baseline. For Example if your Domain Controllers are Windows 2008, build your test environment with Windows 2008 Domain Controllers. Also, verify and duplicate the Domain and Forest functional level of your production environment.

2. Install Active Directory Lightweight Domain Services on a Server. For our purposes it does not matter whether it is an Actual Server or a Physical Server. It also does not matter if it is a Member Server or a Standalone Server. Use LDIFDE to dump your production Schema to an LDF file.

3. Use LDIFDE to dump your production schema to an LDF file.

4. Use LDIFDE to dump your baseline schema to an LDF file.

5. Compare Schema’s with the AD DS/LDS Schema Analyzer.

6. Research any differences in the Schemas.

Step One: Build your Baseline Environment

Step Two: Install Active Directory Lightweight Domain Services on a Server

Install Active Directory Lightweight Directory Services Role on Windows Server 2008. This can be accomplished by Opening Server Manager, navigating to the Roles Node, and Select Add Roles.

Step Three: Use LDIFDE to dump your production Schema to an LDF file

Log on to a domain controller with an account that is a member of the Schema Admins security group, and run the following command to dump the schema to an LDF File:

Ldifde –f <output file name> -d <Distinguished Name of your Schema>

Where <output file name> is the name of the resulting LDF file, and where <Distinguished Name of your Schema> is you guessed it the DN of your schema.

See example below:

Step Four: Use LDIFDE to dump your test Schema to an LDF file

Follow the instructions in Step Three to dump the Schema of the Test Environment you created.

Step Five: Compare Schema’s with the AD Schema

1. Log onto the machine on which you installed Active Directory Lightweight Directory Services.

2. Open a Command Prompt, and Navigate to the “C:\Windows\ADAM” folder.

3. Type “ADSchemaAnalyzer.exe”, and press Enter, this will launch the AD DS/LDS Schema Analyzer Tool.

4. From the Menu, select the “File”, and then select “Load Target Schema…”

5. From the “Load Target Schema” dialog box, click on the “Load LDIF” button.

6. Browse to the LDF file that you created in your production environment, and click on the “Open” Button.

7. From the Menu, select the “File”, and then select “Load base schema…”

8. From the “Load Target Schema” dialog box, click on the “Load LDIF” button.

9. Browse to the LDF file that you created in your test environment, and click on the “Open” Button.

10. From the Schema Menu, select “Hide Present Elements”. This will hide Classes and Attributes that exist in both Schemas.

Expand the “Classes” node in the AD DS/LDS Schema Analyzer.

Step 6: Research any differences in the Schemas

You will now have to research what application created these additional Classes and Attributes. In my example I have a number of Exchange related Classes and Attributes, so it is pretty simple for me to deduce that the additional changes to the Schema came from Exchange.

- Chris ‘I bleed Carolina blue’ Delay

New KB articles related to Directory Services for the week of 1/11-1/17.

Hi, Ned here again. Are you tired of me blogging about DFSR and FRS yet? If so, stop reading. :)

Today I am going to describe the architectural differences of SYSVOL replication on Read-Only Domain Controllers in Windows Server 2008 – FRS versus DFSR. This makes another good case for taking the effort of getting your domain functional levels to 2008 and migrating off of the File Replication Service.

Before I get rolling, a mini-glossary:

RODC - Read-Only DC (Introduced in Windows Server 2008)
RWDC - Writable DC (introduced in Windows 2000 Server)
FRS - File Replication Service (introduced in Windows 2000 Server)
DFSR - Distributed File System Replication (introduced in Windows Server 2003 R2)

Running RODCs with FRS as the replication engine for SYSVOL

While FRS can be used, it has some significant downsides in its behavior if the environment is not carefully administered. Since RODCs are designed to be placed in locations that will not have administrators or very basic role-separated administrators, this can be problematic. FRS does not contain the full plumbing to undo changes, but instead only prevents changes from leaving the DC.

• Files/folders created, modified, or deleted replicate from RWDC to RODC.
• Files/folders created, modified, or deleted do not replicate from RODC to
  RWDC.
  
• All changes within SYSVOL on the RODC survive inbound replication unless the
  same file path was changed upstream.
  
  (Example Scenario)

1. SYSVOL contains 2 policies for Default Domain and Default DC.
2. On the RODC an administrator adds a folder called 'my stuff'.
3. He also manually deletes the registry.pol file from the Default DC policy.
4. He also changes a gpttmpl.inf file to contain no data.
   
   (Outcome)
   
5. The folder called 'my stuff' continues to exist forever, unless deleted on the RODC or created on the RWDC, replicated down, and then deleted on the RWDC.
6. The registry.pol file stays deleted until it is updated on the RWDC and replicated back down to the RODC.
7. The gpttmpl.inf file stays empty until it is updated on the RWDC and replicated back down to the RODC.

As you can imagine, using FRS to replicate RODC SYSVOL folders has some administrative caveats and is not recommended. FRS ,as a feature, has effectively been deprecated (as you can tell from here and the Windows Server 2008 administration tools – where did DFSGUI.MSC go?).

Running RODCs with DFSR as the replication engine for SYSVOL

DFSR offers some architectural advantages that make it very compelling for RODCs.

• Files/folders created, modified, or deleted replicate from RWDC to RODC.
• Files/folders created, modified, or deleted do not replicate from RODC to
  RWDC.
• All changes within SYSVOL on the RODC are undone immediately by the DFSR
  service (i.e. they revert to whatever the RWDC has currently, allowing for replication latency).
  
  (Example Scenario)
  

1. SYSVOL contains 2 policies for Default Domain and Default DC.
2. On the RODC an administrator adds a folder called ‘some goo’.
3. He also manually deletes the contents of the Default Domain policy.
4. He also changes a gpt.ini file to not contain any data.
   
   (Outcome)
5. The folder called 'some goo' is immediately deleted.
6. The missing contents of the Default Domain policy is replicated back in as fast as replication allows.
7. The unmodified gpt.ini file is replicated back in as fast as replication allows.

For these reasons, DFSR-based SYSVOL replication (available when running in Windows
Server 2008 Domain Functional Mode) is recommended.

PS: Have you downloaded Windows Server 2008 R2 yet and deployed DFSR in a test environment? You are in for some surprises there with read-only. You should check that out…

- Ned “My First Born Was Named USN Journal” Pyle

New KB articles related to Directory Services for the week of 1/4-1/11.

Ned here. For those testing Windows 7 administration capabilities, this is for you.

Download here

This is the list of Windows Server 2008 administration tools which are included in Win7 RSAT Client:

Server Administration Tools:
• Server Manager

Role Administration Tools:
• Active Directory Certificate Services (AD CS) Tools
• Active Directory Domain Services (AD DS) Tools
• Active Directory Lightweight Directory Services (AD LDS) Tools
• DHCP Server Tools
• DNS Server Tools
• File Services Tools
• Hyper-V Tools
• Terminal Services Tools

Feature Administration Tools:
• BitLocker Password Recovery Viewer
• Failover Clustering Tools
• Group Policy Management Tools
• Network Load Balancing Tools
• SMTP Server Tools
• Storage Explorer Tools
• Storage Manager for SANs Tools
• Windows System Resource Manager Tools

If you need any kind of support, head on over to the TechNet forums or drop us a line here.

- Ned Pyle

Ned here. You can grab the beta:

Download Windows Server 2008 R2

Remember that unless you are part of TAP, TechBeta, or OEM Beta, there is no support for this product. It is only for evaluation purposes, and should be used in non-production, non-critical environments. Feel free to ask questions here, or visit our Windows Server 2008 R2 forums. The download is in ISO format, and has the following hardware requirements:

Ned here. Come and get it... :)

Press Release 
TechNet Subscribers
MSDN Subscribers

For all others, you'll have to wait until Friday. Oh the humanity.

Just a quick reminder - unless you are part of TAP, TechBeta, or OEM Beta, you cannot get support for Windows 7. If you don't know what those three things are, you aren't in them. This goes for Premier customers, Pro customers, people with MSDN or TechNet Support 5-packs, and the rest - please don't bother trying to open a case with us about it.

This beta is for your evaluation purposes and general lovin', but do not use it for mission critical systems or where problems with your OS is going to cost you money. In short - use your head and enjoy the new OS goodness. :)

If you have already snagged it (public release, TechNet, MSDN, or.. otherwise) make sur to stop by the TechNet forums for any support or bug reporting. And you can always drop us a comment here too, naturally.

- Ned Pyle

Hello AskDS Blog Readers, Mike here again! A common request we hear is how to automatically connect specific network shares to drive letters based on group membership. Mapping network drives based on group membership requires some programming knowledge-- either VBScript or command shell (batch files). VBScript based logon scripts can require hundreds of lines of code to provided a complete solution. And batch files require the assistance of helper applications such as IFMEMBER.EXE and NET.EXE, and introduce many challenges with controlling how Windows processes the script. But Group Policy Preferences removes the programming requirement and awkwardness of scripting mapped drives based on group membership. There are many scenarios in which you may want to map a local drive letter to a specific network share to include public drive mappings, inclusive group drive mappings, and exclusive group drive mappings.

Public drive mappings typically do not require membership to a particular group. However, sometimes public drive mappings do not provide enough granularity. Most organizations have data specific to business units such as accounting, marketing, or human resources.. Inclusive Group Drive mappings solve this problem by allowing a configuration that maps a specific drive letter to a specific network share based on the user being a member of a particular group. This ensures members of the accounting unit receive drive letters mapped for accounting and members of human resources map their respective drives. Exclusive drive mappings are not very common; however, they do provide the flexibility to prevent a user from mapping a particular drive letter to a network share if they are not a member of a specific group. A good example of exclusive drive mappings is to prevent the CIO or other executives members from mapping a drive letter in which they are likely to never use. Let us take a closer look at these scenarios

Public drive mappings

Producing a Group Policy Preference item to create public drive mappings is simple. The GPO containing the preference item is typically linked to higher containers in Active Directory, such as a the domain or a parent organizational unit.

Configuring the drive map preference item.

Figure 1 Configuring mapped drive preference item

Newly created Group Policy objects apply to all authenticated users. The drive map preference items contained in the GPO inherits the scope of the GPO; leaving us to simply configure the preference item and link the GPO. We start by configuring the drive map preference item by choosing the Action of the item. Drive map actions include Create, Replace, Update, and Delete. These are the actions commonly found in most preference items. Create and Delete actions are self-explanatory. The compelling difference between Replace and Update is that Replace deletes the mapped drive and then creates a new mapped drive with the configured settings. Update does NOT delete the mapped drive-- it only modifies the mapped drive with the new settings. Group Policy Drive Maps use the drive letter to determine if a specific drive exists. The preceding image shows a Drive Map preference item configure with the Replace action. The configured location is a network share named data; hosted by a computer named hq-con-srv-01. The configured drive letter is the G drive. All other options are left at their defaults. This GPO is linked at the contoso.com domain.

The results of this configuration are seen when using Windows Explorer on the client computer. The following picture shows a user's view of Windows Explorer. We see there is one network location listed here, which is the G drive that is mapped to \\hq-con-srv-01\data.

Figure 2 Public drive map client view

Later, we'll see how to use exclusive drive mappings with public drive mappings as a way to exclude public drive mappings from a subset of users.

Inclusive drive mapping

Inclusive drive mappings are drives mapped to a user who is a member of (or included) in a specific security group. The most common use for inclusive drive maps is to map remote data shares in common with a specific sub set of users, such as accounting, marketing , or human resources. Configuring an inclusively mapped drive is the same as a public drive mappings, but includes one additional step. The following image shows us configuring the first part of an inclusive drive mapping preference item.

Figure 3 Inclusive drive mapping

Configuring the first part of an inclusive drive mapping preference item does not make it inclusive; it does the work of mapping the drive. We must take advantage of item-level targeting to ensure the drive mapping items works only for users who are members of the group. We can configure item level targeting by clicking the Targeting button, which is located on the Common tab of the drive mapping item. The targeting editor provides over 20 different types of targeting items. We're specifically using the Security Group targeting item.

Figure 4 Security group targeting item

Using the Browse button allows us to pick a specific group in which to target the drive mapping preference item. Security Group targeting items accomplishes its targeting by comparing security identifiers of the specified group against the list of security identifiers with the security principal's (user or computer) token. Therefore, always use the Browse button when selecting a group; typing the group name does not resolve the name to a security identifier.

Figure 5 Configured inclusive security group targeting item

The preceding screen shows a properly configured, inclusive targeting item. A properly configured security group targeting item shows both Group and SID fields. The Group field is strictly for administrative use (we humans recognize names better than numbers). The SID field is used by the client side extension to determine group membership. We can determine this is an inclusive targeting item because of the text that represents the item within the list. The word is in the text "the user is a member of the security group CONTOSO\Management." Our new drive map item and the associated inclusive targeting item are now configured. We can now link the hosting Group Policy object to the domain with confidence that only members of the Management security group receive the drive mapping. We can see the result on a client. The following image shows manager Mike Nash's desktop from a Windows Vista computer. We can see that Mike receives two drive mappings: the public drive mapping (G: drive) and the management drive mapping (M: drive).

Figure 6 Client view of inclusive drive mapping

Exclusive drive mapping

The last scenario discussed is exclusive drive mapping. Exclusive drive mappings produce the opposite results of an inclusive drive mapping; that is, the drive map does NOT occur if the user is a member of the specified group. This becomes usefully when you need to make exceptions to prevent specific drives from mapping. Let's add an exclusive drive mapping to our public drive mapping to prevent specific members of management from receiving the public drive mapping.

Figure 7 Configured exclusive drive mapping

The preceding image shows the changes we made to the public drive mapping (from the first scenario). We've added a Security Group targeting item to the existing public drive mapping preference item. However, the targeting item applies only if the user IS NOT a member of the ExcludePublicDrives group. We change this option using the Items Options list. The client view of manager Monica Brink shows the results of applying Group Policy.

Figure 8 Client view of exclusive drive mapping

This client applies two Group Policy objects; each containing a drive mapping preference item. One item contains our public drive mapping with an exclusive security group targeting item. The other GPO contains the management drive mapping with an inclusive security group targeting item. The client processes the public drive mapping GPO; however, the exclusive targeting item verifies that Monica is a member of the ExcludePublicDrives group. Monica is also a member of the Management group. Therefore, Monica's group memberships prevent her from receiving the public drive mapping and include her in receiving the management drive mapping.

Summary

Drive mapping preference items do not require any scripting knowledge and are easy to use. Leveraging targeting items with drive mapping items increases the power in which to manage drive mapping to users and computers. Public drive mappings are typically linked at higher levels in the domain and generally apply to a large subset (if not all) users. Inclusive drive mappings associate as specific subset of data with a specific group of people, often times mapping to logical divisions within an organization such as accounting, marketing, or human resources. Exclusive drive mappings invert the principals of inclusive drive mappings. The user must not be a member of the specified group for the drive mapping to occur.

Best practices

Be sure to link GPOs high enough in Active Directory so the scope of the drive mapping effects the largest group of user accounts. Obviously, not every GPO should be linked at the domain; however, if there is an accounting organizational unit with three child OUs-- then linking at the Accounting OU effects that largest amount of users. Allow your inclusive and exclusive targeting item to do the bulk of your work. GPOs hosting inclusive drive mappings are best used when the number of user needing the drive mapping are fewer than the number who do not. Exclusive drive mappings are best used when the number of user not requiring the drive mapping are fewer than the number that do. These rules help prevent users from becoming members of too many groups and increasing the cost of managing drive mappings within the organization.

- Mike “Play Some Skynyrd!’ Stephens