Blog - Title

December, 2008

  • New Directory Services KB Articles 12/14-12/21

    New KB articles related to Directory Services for the week of 12/14-12/21.

    959753

    How to customize the default local user profile when you prepare an image of Windows Vista, Windows Server 2008, Windows XP, or Windows Server 2003

    959439

    After you upload encrypted files from a Windows XP-based computer to a WebDAV share, the files remain encrypted

    959438

    On computers that are running Windows Server 2008 and Windows Vista SP1, RSAT GPMC has long delays in domain environments that have many GPOs

    957732

    The returned data is truncated when you use the "repadmin" command to list the number of user accounts or the number of computer accounts in Windows Server 2008

    959873

    You cannot send Start TLS requests from a computer that is running Windows Server 2003 or Windows XP Professional x64 Edition to a server that is running OpenLDAP Software

    960549

    Some third-party Online Certificate Status Protocol (OCSP) clients may reject a response from an OSCP responder if this OCSP responder receives a Response Signing certificate from a Windows Server 2008 certification authority

    961256

    The DNS PTR record might be deleted if you change the DNS server order on a Windows 2003 machine

    961293

    Unable to access Shares "The specified network name is no longer available"

    961302

    Vista and Windows Server 2008 clients are unable to access cluster names with AES-encrypted Kerberos tickets

    961298

    Auto enrollment does not work in the Cross Forest environment

    961299

    The “Group Policy domain controller selection” Group Policy setting does not work as expected

    960417

    When you run an application that uses the SystemTimeToTzSpecificLocalTime function in certain Windows installations, the application performance is very poor

  • Understanding File Date/Time behavior in DFSR Replication (and better ways of knowing that a file has replicated)

    Hi, Ned here again. Mike’s snarky comments notwithstanding, today I am going to talk about how DFSR does and does not replicate file time/date information. I’m also going to give you some advice on examining files to see if they have truly been replicated. Throughout this posting I will be saying ‘file time’, and this also implies ‘file date’.

    Let’s get to it.

    The Misconceptions

    DFSR does not recognize file time changes as a file being modified. Therefore if a file is entirely unchanged in security, in binary contents, or in alternate data streams and has only seen its file time change, the file is not replicated. This is intentional, as we have known third-party applications in the past to only change the time as part of their operations and we did not want to see files get replicated for no reason.

    Now this does not mean that DFSR doesn’t replicate time changes. When a file is modified and replicates normally, the downstream copy receives the new file time of the original.

    The Proof

    So let’s look at this via the DFSR Debug logs (stored as %systemroot%\debug\dfsrxxxxx.log and gz). In this scenario, I used a small internal tool called FILEDATE.EXE to change a files time without otherwise modifying the file.

    20080926 14:26:38.403 1524 LDBX 3548 Ldb::Insert Inserting idRecord: <--File created. It had a date of 2003 (it’s the clock.avi in the Windows folder of all computers)
    + fid 0x3000000002B17
    + usn 0x2900f0
    + uidVisible 0
    + filtered 0
    + journalWrapped 0
    + slowRecoverCheck 0
    + pendingTombstone 0
    + recUpdateTime 16010101 00:00:00.000 GMT
    + present 1
    + nameConflict 0
    + attributes 0x20
    + gvsn {23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81
    + uid {23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81
    <-- UID/GVSN match, this is a new file being added to replication, has never been changed as far as DFSR knows
    + parent {C7147B8D-CCB9-4EAD-B7BA-36F0D816290F}-v1
    + fence 16010101 00:00:00.000
    + clock 20080926 18:26:38.403
    + createTime 20080926 18:26:38.403 GMT
    + csId {C7147B8D-CCB9-4EAD-B7BA-36F0D816290F}
    + hash 00000000-00000000-00000000-00000000
    + similarity 00000000-00000000-00000000-00000000
    + name clock.avi <-- The file

    20080926 14:26:38.418 1524 USNC 2448 UsnConsumer::CreateNewRecord ID record
    created from USN_RECORD:
    + USN_RECORD:
    + RecordLength: 80
    + MajorVersion: 2
    + MinorVersion: 0
    + FileRefNumber: 0x3000000002b17
    + ParentFileRefNumber: 0x2000000002360
    + USN: 0x2900f0
    + TimeStamp: 20080926 14:26:38.403 Eastern Standard Time
    + Reason: Basic Info Change Close Data Extend Data Overwrite File Create <-- USN update for file being created is written to DFSR DB
    + SourceInfo: 0x0
    + SecurityId: 0x69b
    + FileAttributes: 0x20
    + FileNameLength: 18
    + FileNameOffset: 60
    + FileName: clock.avi <-- The file

    <snipped out boring goo>

    20080926 14:26:38.840 2256 OUTC 1056 OutConnection::OpenFile Sent file uid:{23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81 gvsn:{23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81 name:clock.avi fileSize:83348 connId:{29AAE012-2D36-4C4C-BCDD-83CCCE2CCDAC} rgName:0byterepro <-- file is replicated out.

    <snipped out more boring goo>

    20080926 14:27:33.967 1524 LDBX 3665 Ldb::Update Updating idRecord: <-- DFSR DB updated because file has had a USN update
    + fid 0x3000000002B17
    + usn 0x290c40
    + uidVisible 1
    + filtered 0
    + journalWrapped 0
    + slowRecoverCheck 0
    + pendingTombstone 0
    + recUpdateTime 20080926 18:26:38.575 GMT
    + present 1
    + nameConflict 0
    + attributes 0x20
    + gvsn {23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81
    + uid {23B2E6F1-67A8-4A63-85D7-9F0F82271203}-v81
    <-- Note that UID/GVSN unchanged; DFSR does not consider the file to have been modified
    + parent {C7147B8D-CCB9-4EAD-B7BA-36F0D816290F}-v1
    + fence 16010101 00:00:00.000
    + clock 20080926 18:26:38.403
    + createTime 20080926 18:26:38.387 GMT
    + csId {C7147B8D-CCB9-4EAD-B7BA-36F0D816290F}
    + hash 8D69D492-ABA86376-1671B762-8994DE65
    + similarity 2B3E1B27-39113214-39173F1F-3D363D08
    + name clock.avi

    20080926 14:27:33.967 1524 USNC 1879 UsnConsumer::UpdateUsnOnly USN-only update from USN_RECORD: <-- there was a Basic Info change that only affected USN and not the files contents or security
    + USN_RECORD:
    + RecordLength: 80
    + MajorVersion: 2
    + MinorVersion: 0
    + FileRefNumber: 0x3000000002b17
    + ParentFileRefNumber: 0x2000000002360
    + USN: 0x290c40
    + TimeStamp: 20080926 14:27:33.952 Eastern Standard Time
    + Reason: Basic Info Change Close <-- This is date/time being changed to ‘right now’ when I ran FILEDATE.EXE against clock.avi
    + SourceInfo: 0x0
    + SecurityId: 0x69b
    + FileAttributes: 0x20
    + FileNameLength: 18
    + FileNameOffset: 60
    + FileName: clock.avi

    On the downstream server you see… nothing. The GVSN is not updated so DFSR does not believe the file has been modified in a way that requires replication.

    How to tell if files are replicating due to modification the right way

    Ok, so now you’re probably asking me what is the best way to tell if a file has been modified via replication, since looking at the file time is clearly not reliable. Sometimes people try using byte count, but that is just as bad – if I take a 100KB TXT file and change one character inside it from an A to a Z, how will that affect the byte count? It won’t…

    Some better ways would be:

    Get comfortable with the DFSR debug logs and examine them. Here is a downstream server that is adding a file it just replicated in to its local Replicated Folder:

    20080625 17:42:30.956 2416 MEET  2190 Meet::InstallRename File moved. rootVolume:{05853FA6-411C-11DD-A156-806E6F6E6963} parentFid:0x1000000002F8C fidInInstalling:0x4000000002FCC usn:0x70850 updateName:setuplog.txt uid:{B0DAFB7F-1E6D-401E-ADEC-2494F4A345A6}-v16 gvsn:{B0DAFB7F-1E6D-401E-ADEC-2494F4A345A6}-v21 connId:{39D5F13D-B2D1-484D-B57E-E369C8F8C6DD} csName:testrf2 <-- the updated file ‘setuplog.txt’ is moved in.

    <Downstream> 20080625 17:42:30.956 2416 LDBX  3684 Ldb::Update Updating idRecord: <-- the DFSR jet database is updated to reflect that the updated version of the file is now in the content set.
    +    fid               0x4000000002FCC
    +    usn               0x70850
    +    uidVisible        1
    +    filtered          0
    +    journalWrapped    0
    +    slowRecoverCheck  0
    +    pendingTombstone  0
    +    recUpdateTime     16010101 00:00:00.000 GMT
    +    present           1 <-- the file exists in the content set.
    +    nameConflict      0
    +    attributes        0x20
    +    gvsn              {B0DAFB7F-1E6D-401E-ADEC-2494F4A345A6}-v21
    <-- GVSN now matches the originating server information
    +    uid               {B0DAFB7F-1E6D-401E-ADEC-2494F4A345A6}-v16
    +    parent            {5666BB91-265D-42E8-9F57-1B49F4E581B7}-v1
    +    fence             16010101 00:00:00.000
    +    clock             20080625 21:42:30.805
    +    createTime        20080625 21:27:21.734 GMT
    +    csId              {5666BB91-265D-42E8-9F57-1B49F4E581B7}
    +    hash              32B91C5A-74967572-4ABBC3A8-C319BB64
    +    similarity        3F193518-2F152E2B-36262037-05111237
    +    name              setuplog.txt

    Enable DFSR File auditing

    1.    Create the following registry *key* (not value): 
        HKLM\SYSTEM\CurrentControlSet\Services\Dfsr\Parameters\Enable Audit

    (Note – there is a space between ‘Enable’ and ‘Audit’)

    2.    Enable Object Access Auditing for these servers (via local or domain-based group policy) for SUCCESS.

    3.    Refresh policy with GPUPDATE /FORCE (there should be no need to restart DFSR or the servers)

    4.    Replicate a new file from upstream to downstream partner.

    5.    In Event Viewer | Security Events on the upstream partner, you will see:

    Event Type: Success Audit
    Event Source: DFSR
    Event Category: (3)
    Event ID: 7002
    Date: 2/16/2006
    Time: 10:33:50 AM
    User: NT AUTHORITY\SYSTEM
    Computer: M3
    Description:
    The DFS Replication service served the following file:

    Additional Information:
    Replicated Folder Root: C:\Sales
    Replicated Folder Name: Sales
    Replicated Folder ID: 3B38DDC2-FFBF-428C-9853-71D2D2D65351
    File Name: test.txt
    File ID: {B4738E50-CED1-4DA0-94CF-0E21345F98F6}-v2328331
    File Parent ID: {3B38DDC2-FFBF-428C-9853-71D2D2D65351}-v1
    Partner name: M1.contoso.com

    6.    In Event Viewer | Security Events on the downstream partner, you will see:

    Event Type: Success Audit
    Event Source: DFSR
    Event Category: (3)
    Event ID: 7004
    Date: 2/16/2006
    Time: 10:33:50 AM
    User: NT AUTHORITY\SYSTEM
    Computer: M1
    Description:
    The DFS Replication service received the following file:

    Additional Information:
    Replicated Folder Root: C:\Sales
    Replicated Folder Name: Sales
    Replicated Folder ID: 3B38DDC2-FFBF-428C-9853-71D2D2D65351
    File Name: test.txt
    File ID: {B4738E50-CED1-4DA0-94CF-0E21345F98F6}-v2328331
    File Parent ID: {3B38DDC2-FFBF-428C-9853-71D2D2D65351}-v1
    Partner name: M3.contoso.com

    Use LOGPARSER to give you a checksum comparison

    1.    Download Logparser Goodness.

    2.    Calculate the MD5 hash from each copy of the file, for example:

    C:\Program Files (x86)\Log Parser 2.2>LogParser.exe "SELECT Path, HASHMD5_FILE(Path) FROM \\server1\rf\goo.txt" -i:FS -recurse:0

    Path                    HASHMD5_FILE(Path)
    ----------------------- --------------------------------
    \\server1\rf\goo.txt    76EC538F73B542A2BEFA18A88717054B

    C:\Program Files (x86)\Log Parser 2.2>LogParser.exe "SELECT Path, HASHMD5_FILE(Path) FROM \\server2\rf\goo.txt" -i:FS -recurse:0

    Path                    HASHMD5_FILE(Path)
    ----------------------- --------------------------------
    \\server2\rf\goo.txt    BBD8E74F23D7605CB0CDB57A1B25D826

    Here I can see that the files are not the same, because the file changed on one and not yet replicated. If they were the same I’d know the files are in sync. Note that this checksum just shows the binary data portions of the file hash. DFSR also calculates metadata such as security ACL's, so a file could be different in more ways than just its contents.

    Notes

    If you want to understand a bit more about the underlying architecture of NTFS file times (or you just crave a cure for your chronic insomnia), be sure to check out:

    Description of NTFS date and time stamps for files and folders

    Change Journal Records

    File Times

    FILETIME Structure

    If we don’t chat again, Merry Christmas and a Happy New Year. :-)

    - Ned Pyle

  • New Directory Services KB Articles 12/07-12/14

    New KB articles related to Directory Services for the week of 12/07-12/14.

    959887

    You cannot use a smart card certificate to log on to a domain from a Windows Vista-based client computer

    955558

    You cannot use a smart card certificate to log on to a domain from a Windows Vista-based or a Windows Server 2008-based client computer

    958909

    It may take a long time to log on to a Windows Vista-based computer that has antivirus software installed, and you may notice that the file size of the Setupapi.app.log file is very large

    960837

    All user accounts are disabled or the computer restarts continuously on a Windows XP-based or Windows Vista-based computer that has Windows SteadyState installed

    959202

    The Active Directory Users and Computers snap-in cannot display service principal names (SPNs) that have non-numeric port values when you configure the Delegation properties of a computer account in Windows Server 2003

  • AGPM Least Privilege Scenario

    Mike here again. A customer recently asked how they should configure their Advanced Group Policy Management (AGPM) server using the least amount of privileges. AGPM Program Manager, Michael Kleef, posted a quick task list on his TechNet blog(http://blogs.technet.com/mkleef/archive/2008/11/18/locking-down-agpm-fit-for-least-privilege.aspx) , but I thought I'd take the opportunity to go into more detail and provided some additional suggestions.

    AGPM adds role-based administration, change control, workflow, and granular delegation to Group Policy Management. These features allow you to use AGPM to delegate Group Policy creation, review and deployment to non-administrative users. You can read more information about AGPM by downloading the Advance Group Policy Management Overview whitepaper (http://go.microsoft.com/fwlink/?LinkId=106067).

    Least privilege requirements

    AGPM least privilege configurations can vary slightly. The variance largely depends on how little of privileges you want to provide to the AGPM Server (actually the service account running the AGPM Service). Regardless, you need to achieve the following four requirements for the AGPM Service to work properly:

    • The AGPM Service account requires full access to the AGPM archive folder
    • The AGPM Service account requires full access to the local computer's temp folder
      (%systemroot%\temp)
    • Full access to GPOs created prior to using AGPM
    • The AGPM Service account must be a member of the Group Policy Creator Owners and Backup Operators Group

    The AGPM Service account

    There are two options when choosing the AGPM Service account: Local System or an actual domain user account used to run the service. Least privilege scenarios cannot use the Local System account. The AGPM service can only use the Local System account when the service is running on a domain controller. Yes, the AGPM service can run on a domain controller; however, it's highly advisable not to install it on a domain controllers. Domain controllers have a specific purpose in the infrastructure just as Exchange or SQL servers-- domain controllers authenticate users. The last thing you'll want to do is restore a domain controller because your AGPM Server had a problem. I typically suggest naming the service account something intuitive-- like AGPMService.

    Archive folder

    The AGPM Service requires Full Control of the archive folder. The archive folder is where the AGPM Server keeps a manifest and backups of controlled GPOs. The default archive for AGPM version 3.0 is %ProgramData%\Microsoft\AGPM

    Temp folder

    The AGPM Service uses GPMC application programming interfaces (APIs) to accomplish many GPO operations. Many of these APIs use the computer's temp folder for temporary storage. You must grant the AGPM Service account Full Control to the computer's temp folder, which is %systemroot%\temp.

    Full Access to existing GPOs

    AGPM ensures that it has proper ownership and permissions to all controlled GPOs. However, GPOs created before implementing AGPM will not provided adequate permissions to the AGPM Service. For this reason, you'll want give the AGPM Service Full Control to all GPOs that exists prior to implementing AGPM.

    Group memberships

    The AGPM Service requires membership in two groups: Group Policy Creator Owners and Backup Operators.

    Group Policy Creator Owners

    By Default, Windows only allows Domain Administrators and Group Policy Creator Owners to create Group Policy objects. The least privilege configuration requires you to make the AGPM Service account a member of Group Policy Creator Owners. Membership in the Group Policy Creator Owners group allows the AGPM service to create Group Policy objects , makes the AGPM Service the owner of the new Group Policy object, and gives it the permissions required to manage the Group Policy object.

    Backup Operators

    Some of the operations that occur in AGPM mimic the functionality found in backup software. For example, the AGPM service may need to change the owner of a Group Policy object. Granting ownership to a security principal different from yourself is a privileged operations. Including the AGPM service account in the Backup Operators group provides it with the privilege to grant ownership. Backup Operators is a well-known security identifier found on each Windows Server. The AGPM Service attempts to change ownership on Group Policy objects, which are stored on the domain controller. The ownership change operation occurs at the domain controller, so you need to make sure the AGPM Service account is in the Backup Operators group on the domain controllers. Membership to the Backup Operators account on the AGPM Server is not required.

    Troubleshooting

    You can run across some configuration issue when attempting to configure the AGPM Server in a least privilege scenario. The following are the most common errors seen during an AGPM least privilege scenario.

    [GPMC Error] Could not take ownership of the production GPO. Value does not fall within the expected range

    image

    Figure 1- Value does not fall within the expected range error

    This error is discoverable when attempting to delete a controlled Group Policy object. The error occurs when choosing Delete GPO from archive only or Delete GPO from archive and production.

    Solution

    The AGPM Service is configured for least privileges and is not a member of Backup Operators on the domain controller. The AGPM service is attempting to grant ownership to a security principal in which it is not allowed. Add the AGPM service account to Backup Operators on the domain controller. Restarting the AGPM service is not a requirement.

    [Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML.

    image

    Figure 2- GpReport.xml error

    This error is discoverable when attempting to create a new controlled Group Policy object. There are two major causes of this error

    Solution 1:

    The AGPM service does not have permissions to the computer's temp folder. Ensure the AGPM service has Full Control to the %systemroot%\temp folder of the computer running the AGPM Server service.

    Solution 2:

    First, check solution 1. Permissions on the computer's temp folder is root cause of the problem and you'll want to fix that first. If you are still receiving the error after following solution 1 (or temporarily making the AGPM service account a local admin of the computer running the AGPM Server service and restart the service), then the root cause of the problem occurred when you attempted to create your first controlled Group Policy object. The template created during the first controlled GPO creation failed (most likely with the this warning [GPMC Warning] A Report for this GPO could not be created. The backup will not contain any report of the settings Details: 0x80131509).

    image

    Figure 3- AGPM Templates view

    Therefore, all subsequent controlled GPOs created from the template fail with [Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML. You need to Delete and Destroy all templates created before you followed solution 1 (permissions on the temp folder). Templates created before following solution 1 contain invalid XML.

    image

    Figure 4- Destroying template from AGPM Recycle Bin

    After deleting and destroying invalid templates (specifically the <Empty GPO> template), then create a new controlled Group Policy object. You'll be prompted to create a new template. Agree to the create the new template. The operation takes longer than expected; however, it should return successful.

    That's all the time we have for this episode of AskDS: AGPM Least Privilege Scenario. Tune in next time to read Ned Pyle's latest saga about DFSR :)

    - Mike Stephens

  • Troubleshooting ADPREP Errors

    Hi all, Rob Newhouse again, and today I am talking about errors that you may see while running ADPREP. Normally I do not like to create a laundry list of errors, however I believe it should be beneficial and save you some time and (maybe) money by posting these common errors. This is a follow up to my previous post So You Want to Upgrade to Windows 2008 Domain Controllers (ADPREP).

    So you have run ADPREP and it has failed. The first thing that you need to do is open your C:\Windows\Debug\Adprep\Logs folder. There will be a separate file each time that you run ADPREP.
    At the bottom of the file, you will see what the problem is. Common failures include:

    Errors Running Adprep /Forestprep

    Adprep Was Unable to Extend the Schema

    Adprep was unable to extend the schema.

    [Status/Consequence]

    The schema master did not complete a replication cycle after the last reboot. The schema master must complete at least one replication cycle before the schema can be extended.

    [User Action]

    Verify that the schema master is connected to the network and can communicate with other Active Directory Domain Controllers. Use the Sites and Services snap-in to replicate between the schema operations master and at least one replication partner. After replication has succeeded, run adprep again.

    Solution

    This error indicates that there are AD replication problems in the environment. In order to continue the replication issue must be resolved.

    To check what replication problems you are having install your Windows Support tools and run Repadmin /Showrepl or Repadmin /Showreps on the Schema Master. This should show you which DC’s you are having problems with.

    Once you have determined the DC (s) that has the problem, check to see if you can connect to \\server(servername) and \\FQDN(servername)

    If both are unsuccessful then you may have a networking problem, a broken secure channel or a 5 minute time difference between the two machines.

    If one is unsuccessful you have a networking problem involving DNS or Netbios name resolution.

    If both are successful:

    On both the DC that is not replicating with the Schema Master as well as the Schema Master:

    1. In the TCP\Nic properties point DNS to a single DNS server
    2. At a cmd prompt type
    3. Netdiag /fix

    On the Schema Master

    1. Open Active Directory Sites and Services
    2. Expand the site that the Schema Master is in
    3. Right click on the NTDS settings under the Schema Master and choose All Tasks\Check Replication topology.
    4. Refresh the view
    5. Right click on each replication object and attempt a replication

    These are just some basic troubleshooting steps. If you get an error message, go to Support.Microsoft.com and in the search type in the error message in quotes.

    User Not a Member of Required Groups

    Adprep detected that the logon user is not a member of the following groups: Enterprise Admins Group, Schema Admins Group and Contoso.local\Domain Admins Group.

    [Status/Consequence]

    Adprep has stopped without making changes.

    [User Action]

    Verify the current logged on user is a member of Enterprise Admins group, Schema Admins group and Contoso.local\Domain Admins group.

    - Or -

    Adprep was unable to check the current User's group membership

    [Status/Consequence]

    Adprep has stopped without making changes.

    [User Action]

    Verify the current logged on user is a member of Domain Admins Group, Enterprise Admins group and Schema Admins group if /forestprep is specified, or is a member of Domain Admins group if /domainprep is specified.

    Adprep encountered a Win32 error.

    Error code: 0x5 Error message: Access is denied

    Solution

    Check your group membership. If you are a member of many nested groups, you may experience the problem due to your token size. In this case, you may choose to create a new account in Active Directory Users and computers, make the new account a member of the Domain Admins, Enterprise Admins, and Schema Admin groups only, logon to the Schema Master as that account and rerun the Adprep /ForestPrep command.

    As an alternative to creating a new account you can

    1. Increase Maxtokensize in the registry

    a) Open Regedit
    b) Navigate to HKLM\System\Current Control Set\Control\Lsa\Kerberos\Parameters
    c) Add a new Dword
    d) MaxtokenSize
    e) Value 65535

    or

    2. Remove all unnecessary groups

    ADPREP not Running on Schema Master

    ADPREP WARNING:

    Before running adprep, all Windows 2000 Active Directory Domain Controllers in the forest should be upgraded to Windows 2000 Service Pack 4 (SP4) or later.

    [User Action]

    If ALL your existing Windows 2000 Active Directory Domain Controllers meet this requirement, type C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.

    C

    Forest-wide information can only be updated on the Active Directory Domain Controller that holds the schema operations master role.

    [Status/Consequence]

    Adprep has stopped on this Active Directory Domain Controller and must be run on the current schema operations master, which is Rob731.Contoso.local.

    [User Action]
    Log on to the Rob731.Contoso.local Active Directory Domain Controller, change to the directory of adprep.exe on the installation media, and then type the following command at the command prompt to complete the forest update: adprep /forestprep

    Solution

    On rare occasions you may experience this message when you are on the schema master. In these cases transfer the schema master to another DC and then transfer it back to the original and run Adprep /Forestprep again. See also How to view and transfer FSMO roles in the graphical user interface.

    If your schema master was on another machine that was removed from Active Directory then you will have to seize the schema master Role using Ntdsutil. See also Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller.

    In your Adprep log you see “Error 0x80070020 (Error_sharing_Violation)”

    Solution

    This is normally caused by antivirus programs' on-demand scanning. To resolve the issue, disable the antivirus software on-demand scanning feature.

    Adprep /Forestprep Fails Due To OID Conflict On Any Schema Attribute

    “OID will not be changed resulting in probable failure to add a new class.”

    Solution

    This error happens when custom schema changes have been made, or when a third-party software makes schema changes that conflict with Microsoft’s.

    What you will see is “OID will not be changed resulting in probable failure to add a new class.”

    To resolve this issue, open the ADPREP log to see what the failed object is. If you know the third-party software that is using the attribute, contact them and determine if there is a fix. Otherwise I would recommend opening a case with Microsoft for assistance resolving this issue.

    Schema update failed: An attribute with the same link identifier already exists.

    This error occurs when you are trying to update/add an object in the schema and the link identifier already exists for another attribute. Some third party apps will modify the schema with a link identifier set that is owned by the OS.

    You will see the following in the CMD prompt window. The key here is the message about link identifier.

    Connecting to "Machine"
    Logging in as current user using SSPI
    Importing directory from file "D:\Sources\adprep\schXX.ldf"
    Loading entriesAdd error on line 249: Unwilling To Perform
    The server side error is "Schema update failed: An attribute with the same link identifier already exists."
    15 entries modified successfully.
    An error has occurred in the program
    ................
    Opened Connection to Machine
    SSPI Bind succeeded
    Current Schema Version is 30
    Upgrading schema to version 44
    ERROR: Import from file D:\Sources\adprep \sch34.ldf failed. Error file is saved in ldif.err.34.

    When you look in the ldif.err.XX log you will see the attribute we are trying to add:

    Entry DN: CN=ms-PKI-AccountCredentials,CN=Schema,CN=Configuration,DC=Contoso,DC=local
    Add error on line 249: Unwilling To Perform The server side error is "Schema update failed: An attribute with the same link identifier already exists."An error has occurred in the program."

    Solution

    In this instance please contact Microsoft for a resolution.   This error indicates that there is a link identifier that is already in use that shouldn’t be there.

    Errors Running Adprep /Domainprep

    Forestprep Not Run Or Not Recognized As Having Been Run

    Running domainprep ...
    Forest-wide information needs to be updated before the domain-wide information can be updated.

    [User Action] 

    Log on to the schema master Rob731.Contoso.local for this forest, run the following command from the installation media to complete the forest update first:  adprep.exe /forestprep and then rerun adprep.exe /domainprep on infrastructure master again.

    Solution

    This problem can happen if you haven’t run Adprep /Forestprep yet, or if replication is broken and you are running it on a different DC or Domain than you ran the Adprep /Forestprep on. To resolve this issue either run Adprep /Forestprep or resolve the replication issue depending on the situation.

    Not In Windows 2000/2003 Native Mode

    Adprep detected that the domain is not in native mode

    [Status/Consequence]

    Adprep has stopped without making changes.

    [User Action] 

    Configure the domain to run in native mode and re-run domainprep
    Raise the domain functional level to 2000 Native mode
    To raise Windows 2003 to native mode
    1)    Open Active Directory Users and computers
    2)    Right click on your domain name and select Raise Domain Functional Level
    3)    Use the drop down to select Windows 2000 Native Mode
    4)    Click Raise

    clip_image002

    Unable To Contact Infrastructure Master

    Adprep was unable to check the domain update status.

    [Status/Consequence]

    Adprep queries the directory to see if the domain has already been prepared. If the information is unavailable or unknown, Adprep proceeds without attempting this operation. 

    [User Action] 

    Restart Adprep and check the ADPrep.log file. Verify in the log file that this domain has already been successfully prepared.
    Adprep encountered a Win32 error.  Error code: 0x3a Error message: The specified server cannot perform the requested operation..
    Check connectivity to the Infrastructure Master.

    Errors Running Adprep /Domainprep

    If you have already run Adprep domain prep, there is really only one error that you can get. When you run the Adprep /Domainprep /Gpprep after you have done the normal Domainprep you are only setting permissions on the policies folder. Below is the error that you will receive if they are inaccessible.

    Group Policies Missing Or Inaccessible

    Adprep was unable to complete because the call back function failed. 

    [Status/Consequence]

    Error message: (null)

    [User Action] 

    Check the log file ADPrep.log, in the C:\WINDOWS\debug\adprep\logs\20080806171216 directory for more information

    Solution

    Check to make sure that your sysvol\sysvol\policies\{6ac…………..} and {31b…………….} folders exist and are accessible. If either or both are missing and you have a backup of these folders, restore the folders. If you do not have a backup and the folders are not in an NTFRS_Policies folder, then contact Microsoft for assistance in recreating the folders.

    Errors Running Adprep /Rodcprep

    Adprep /Rodcprep Fails Due To Insufficient Permissions

    Adprep connected to the domain FSMO: Rob731.Contoso.local.

    Adprep found partition DC=ForestDnsZones,DC=Contoso,DC=local, and is about to update the permissions.

    Adprep connected to a replica DC Rob731.Contoso.local that holds partition DC=ForestDnsZones,DC=Contoso,DC=local.

    Adprep was unable to modify the security descriptor on object DC=ForestDnsZones,DC=Contoso,DC=local.

    [Status/Consequence] 

    ADPREP was unable to merge the existing security descriptor with the new access control entry (ACE).

    [User Action] 

    Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080813153240 directory for more information.
    Adprep encountered an LDAP error.  Error code: 0x32. Server extended error code: 0x5, Server error message: 00000005: SecErr: DSID-03151D54, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

    Adprep failed the operation on partition DC=ForestDnsZones,DC=Contoso,DC=local. Skipping to next partition.

    Solution

    You will see other partitions DC=domainDnsZones,DC=Contoso,DC=local as well. To fix this issue make sure you are in the Domain Admins and Enterprise Admins groups.

    Adprep /Rodcprep Fails Because It Cannot Connect To Domain Naming Master

    Adprep could not contact the Domain Naming FSMO to read the partitions. The Domain Naming FSMO must be reachable for this operation to proceed. 

    [Status/Consequence]

    The Active Directory Domain Services DNS partitions are not prepared for Read Only DCs.

    [User Action] 

    Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080813175105 directory for possible cause of failure.
    Adprep encountered a Win32 error.  Error code: 0x54b Error message: The specified domain either does not exist or could not be contacted..

    Solution

    This error indicates that there is a problem with the domain naming master. Verify that you can contact the Domain Naming Master for the forest. You can check the operations master role in Active Directory Users and Computers.

    Adprep /Rodcprep Fails Because It Cannot Connect To Infrastructure Master

    Adprep found partition DC=Contoso,DC=local, and is about to update the permissions.
    Adprep could not contact the Infrastructure FSMO for domain DC=Contoso,DC=local. The Infrastructure FSMO must be reachable for this operation to proceed. 

    [Status/Consequence]

    The Active Directory Domain Services DNS partitions are not prepared for Read Only DCs.

    [User Action]

    Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080814090356 directory for possible cause of failure.
    Adprep encountered a Win32 error.  Error code: 0x3a Error message: The specified server cannot perform the requested operation..
    Adprep failed the operation on partition DC=Contoso,DC=local. Skipping to next partition.

    Adprep completed with errors. Not all partitions are updated. See the ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080814090356 directory for more information. To successfully update all partititions, the current logged on user needs to be a member of Enterprise Admins group. If that is not the case, please correct the problem, and then restart Adprep.

    Solution

    On the Schema Master run the following command:

    Netdom Query FSMO

    You should see the five FSMO roles including the Infrastructure Master. Once you have determined who the Infrastructure master is type \\Servername and \\FQDN(servername). Ensure that you can connect to the Infrastructure master

    If you need to transfer or seize the Infrastructure master for any reason follow:

    Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller

    Or

    How to view and transfer FSMO roles in the graphical user interface

    This concludes this post on many of the errors that you may encounter while running ADPREP. For those reading this after running into an error, I hope that it helped to resolve the issue.

    - Rob Newhouse

  • New Directory Services KB Articles 11/30-12/07

    New KB articles related to Directory Services for the week of 11/30-12/07.

    958876

    When you try to update a file that has a newer version on a Windows Server 2003 R2-based DFSR server, the operation fails, the original file is deleted from the replication partners, and event 4412 and event 4502 are logged

    958838

    Changes that are made to security groups or to distribution groups are not replicated to destination domain controllers when you use link value replication in a Windows Server 2003 environment

    954312

    FIX: Certificate error when you try to visit an SSL Web site by using Internet Explorer 7: "There is a problem with this website's security certificate"

    955839

    December 2008 cumulative time zone update for Microsoft Windows operating systems

  • Why Are ADFS Binaries Installed on non-R2 Windows Server 2003 computers?

    Hi, Warren here. I recently worked on a case where I got to do a bit of sleuthing. I found the results interesting and thought other Windows Server admins might notice the same thing this particular administrator had and wonder why.

    My customer has an all Windows 2003 Standard Edition environment. Windows 2003 R2 servers are not deployed. All the servers are built from a carefully managed image. No files are to be allowed on the image if they cannot be accounted for.

    This administrator noticed that on all of his servers there is an Active Directory Federated Services (ADFS) directory (%systemdrive%\ADFS) complete with the ADFS binaries. He also has noticed that some of the servers have the ADFS binaries installed in the .NET Global Assembly Cache (GAC) while others do not. The GAC is located at %systemroot%\assembly.

    This is only interesting because ADFS is only available on Windows Server 2003 R2 and Windows 2008. My customer needed to know how and why these ADFS files are installed on his servers and why some of his servers had the ADFS binaries installed in the GAC while others did not.

    After researching and testing I was able to determine the root cause of the issue. ADFS binaries will be installed on Windows 2003 Standard Edition when hotfix 920764 or Service Pack 2 is installed (as that hotfix is included in SP2).

    Now how do we explain why some of the systems had the ADFS binaries installed in the GAC and others did not?

    If .NET 2.0 is installed on a normal (non-R2) 2003 server, and you then apply SP2 you will get the ADFS directory created with the ADFS DLLs in itand the ADFS DLLs installed in the GAC.

    If .NET 2.0 is not installed when you apply SP2 you still get the ADFS directory with the ADFS DLLs installed in it, but the ADFS DLLs do not get installed in the GAC.

    While this is not earth-shaking news, it may prove helpful to those who need to explain where the ADFS directory and files on their servers came from or it may at a minimum provide an interesting bit of Windows trivia.

    If you are interested in learning more about ADFS or the GAC start with these links below:

    Global Assembly Cache - http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx

    Active Directory Federated Services - http://www.microsoft.com/windowsserver2003/techinfo/overview/adfsoverview.mspx

    - Warren Williams

  • One stop shopping for DFSR and DFSN recommended hotfixes

    Hi, Ned here again. We have put up a new(ish) KB article that will allow you to always see the latest recommended hotfixes for DFSR and DFSN. I also updated the ever popular 'Top 10 Common Causes of Slow Replication with DFSR' blog post to reflect this, and I hope you make this a favorite going forward.

    KB958802 - List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2003 R2

    We still have a couple edits pending check-in for this KB, but at any time this is officially the latest binary goo.

    For the (excellent) questions of:

    1. Can these start being distributed through Windows Update?
    2. Can DFSR itself tell me that I should use newer versions?

    ... I have no comment. Windows Server 2008 R2 development has all hands on deck right now of course, so please bear with us.

    - Ned Pyle