Location: List Archives

List Archives

This forum is an archive of all posts to our mailing list over the past few years.  The forum is set read only therefore to contribute you will need to join our list community.  See more info about this here.

 

When subscribed to the list you should use your standard email client to send your posts to ActiveDir@mail.activedir.org.

List Archives

Subject: [ActiveDir] Running dcdiag /q before upgrading AD to 2008 R2
Prev Next
You are not authorized to post a reply.

AuthorMessages
AlRoseUser is Offline

Posts:44

06/07/2010 9:42 AM  
Hi everyone,

Prior to upgrading our AD to 2008 R2 i would like to make sure about AD's
health.

Running a dcdiag /q on my DCs gives an error:
There are warning or error events within the last 24 hours after the SYSVOL
has been shared. Failing SYSVOL replication problems may cause Group Policy
problems.

Running gpotool
Error: dc02.eu.acme.com - AMSTERDAM-DC01.eu.acme.com sysvol mismatch
Error: dc02.eu.acme.com - wroclaw-dc01.eu.acme.com sysvol mismatch
Error: dc02.eu.acme.com - amal-dc02.eu.acme.com sysvol mismatch

I have installed Ultrasound to monitor FRS but so far all lights are green.

Can somone point me to the right direction to troubleshoot the issue. After
a bit of googling i found that you can change manually the sysvol version
but i am not sure about consequences.

Thank you

matheeshaUser is Offline

Posts:34

06/07/2010 10:47 AM  
The GPOTool is reporting issues in FRS replication that may have been fixed
since then. If Ultrasound says all is well then thats a good sign.

I would do a FRS convergence/propagation test from Ultrasound and see if
successful. Else just drop a small file on each DC's SYSVOL with the name
like <dcname>.txt and then after check to see if eventually all DCs have a
list of txt files in that folder representing all the DC's from the domain.
Missing text file names indicate which DC's update you havent yet received.
Note if you have 5 DCs, you'd check all 5 to ensure they all have 5 text
files representing each DC name.
http://blogs.technet.com/b/askds/archive/2008/05/22/verifying-file-replication-during-the-windows-server-2008-dfsr-sysvol-migration-down-and-dirty-style.aspx
has
similar details.

GPOTool is comparing the version information in AD with gpt.ini details for
the same policy. So say you have the default domain policy in
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=Domain,DC=COM.
it will look at version number (versionnumber attribute) and read the
version number from the same policy's SYSVOL folder containing the settings.
gPCFileSysPath attribute indicates the relevant SYSVOL path and gpt.ini has
a entry called version like Version=721268. if they dont match, you get the
error shown.

When you edit policies using GPMC , the policy version number increments.
This is written to AD object and to the relevant line in gpt.ini. Say you
have a policy with a version of 5. Imagine you had some FRS replication
errors which meant a DC where you edited a policy may have the changes
committed to gpt.ini (now version 6) and the relevant files in that GUID
folder not go out. But if AD replication works, then the details regarding
the policy version number (attribute versionnumber=6) increase will go out.
This is likely as AD replication can be fixed within the tombstone
lifetime (generally 60 or 180days and thus giving you ample time to fix it)
and so eventually its likely that the AD changes get out. But FRS changes
could be lost in situations such as journal wrap (say you non auth restore
of the SYSVOL using a DC with the policy at version=5). Now everyone has
versionnumber=6 in AD while gpt.ini in SYSVOL for that specific policy will
say version=5 or so.

Note these version numbers arent to be taken literally as they are stored
to represent version of computer and user portions of the policy within the
same number. You actually would take the version number stored in AD (say
721268), paste into calc.exe as a decimal and convert to hex (B0174). Here
is the last 4 digits (0174 in hex) represent computer portion version (372
decimally) and the first 4 digits (in this case simply B in Hex) represent
user portion (11 decimally).

For each policy if you ran gpotool and if the AD/SYSVOL numbers were say
6/5, that means all DCs have the same older version of policy (the changes
done for version 6 were lost and no DCs have it all. the version number has
simply increased). But if one DC says 6/6 while others say 6/5, then that
means two DCs *potentially *have different versions of the policy (I say
potentially as the only files different may be simply gpt.ini and not the
significant files like registry.pol and so on. Apologies if its too much
theory at this point).

The point is based on the data you'e given if this is the only issue
present, it merely means some policies have version information out of sync
and will affect whomever is a client (machine or user) that is interested in
processing settings within that specific policy. If you had FRS issues, it
will prevent specific changes done during upgrade. Only one I can think of
is the "adprep /domainprep /gpprep" command. But if you've done it before
for that domain, then you dont need to run it again for that domain.
Otherwise if AD replication and FRS is working, there is a good chance the
adprep commands themselves will work (and replicate out) and that you'd be
able to promote some 2008 R2 DCs into the forest.

http://technet.microsoft.com/en-us/library/upgrade-domain-controllers-to-windows-server-2008-r2(WS.10).aspx
has
some very good information (some of which are checklists of pre-post upgrade
tasks) which you should digest before going ahead. Specifically look out for
issues that you might run into due to the security settings that are
tightened by default. And do move to DFSR based SYSVOL as soon as possible
post upgrade.

HTH

M@

On 7 June 2010 09:40, Al Rose <arose107@gmail.com> wrote:

> Hi everyone,
>
> Prior to upgrading our AD to 2008 R2 i would like to make sure about AD's
> health.
>
> Running a dcdiag /q on my DCs gives an error:
> There are warning or error events within the last 24 hours after the SYSVOL
> has been shared. Failing SYSVOL replication problems may cause Group Policy
> problems.
>
> Running gpotool
> Error: dc02.eu.acme.com - AMSTERDAM-DC01.eu.acme.com<http://amsterdam-dc01.eu.acme.com/>sysvol mismatch
> Error: dc02.eu.acme.com - wroclaw-dc01.eu.acme.com sysvol mismatch
> Error: dc02.eu.acme.com - amal-dc02.eu.acme.com sysvol mismatch
>
> I have installed Ultrasound to monitor FRS but so far all lights are green.
>
> Can somone point me to the right direction to troubleshoot the issue. After
> a bit of googling i found that you can change manually the sysvol version
> but i am not sure about consequences.
>
> Thank you
>

sdelrioUser is Offline

Posts:14

06/07/2010 11:07 AM  
Hi Al,

First at all I would like to know if there is any FRS replication issue
there, if you test to create a folder is that folder replicated to all of
that DCs?

If the replication is actually working fine , you can follow this
instructions to match the version number , then force the replication to
propagate the changes, check if has replicated fine and as last step , check
if the GPOTOOL does not show the error anymore

1.Run GPOTool (from the Resource Kit) and get the output

2. On the PDC Emulator only: Open the GPT.ini file located under
Sysvol/sysvol/<dom
name>/Policies/ <Guid for Default domain pol>

3.Carefully change the Version number to match the version number of the DS
from
the GPOTool output

4.This should replicate within a short time.

5.Verify the replication by checking other DCs.

6.Make another small change to the policy and make sure the version numbers
increment correctly





On Mon, Jun 7, 2010 at 5:40 AM, Al Rose <arose107@gmail.com> wrote:

> Hi everyone,
>
> Prior to upgrading our AD to 2008 R2 i would like to make sure about AD's
> health.
>
> Running a dcdiag /q on my DCs gives an error:
> There are warning or error events within the last 24 hours after the SYSVOL
> has been shared. Failing SYSVOL replication problems may cause Group Policy
> problems.
>
> Running gpotool
> Error: dc02.eu.acme.com - AMSTERDAM-DC01.eu.acme.com sysvol mismatch
> Error: dc02.eu.acme.com - wroclaw-dc01.eu.acme.com sysvol mismatch
> Error: dc02.eu.acme.com - amal-dc02.eu.acme.com sysvol mismatch
>
> I have installed Ultrasound to monitor FRS but so far all lights are green.
>
> Can somone point me to the right direction to troubleshoot the issue. After
> a bit of googling i found that you can change manually the sysvol version
> but i am not sure about consequences.
>
> Thank you
>

AlRoseUser is Offline

Posts:44

06/07/2010 3:10 PM  
Apparently i do have FRS replication issues.

I have created a txt file under \\domain\sysvol\domain path and then i ran
frsdiag Propagation File Tracer. After more than 10 minutes, all DCs are not
getting the file.

The frslog file contain:

Checking for errors/warnings in FRS Event Log ....

NtFrs 4/24/2010 11:37:40 AM Error 13568 The File Replication Service has
detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in
JRNL_WRAP_ERROR.
Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\windows\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to
read from the NTFS USN journal is not found. This can occur because of one
of the following reasons.
Ώ] Volume "\\.\C:" has been formatted.
ΐ] The NTFS USN journal on volume "\\.\C:" has been deleted.
Α] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can
truncate the journal if it finds corrupt entries at the end of the
journal.
Β] File Replication Service was not running on this computer for a long
time.
Γ] File Replication Service could not keep up with the rate of Disk IO
activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1
will cause the following recovery steps to be taken to automatically
recover from this error state.
Ώ] At the first poll, which will occur in 5 minutes, this computer will be
deleted from the replica set. If you do not want to wait 5 minutes, then
run "net stop ntfrs" followed by "net start ntfrs" to restart the File
Replication Service.
ΐ] At the poll following the deletion this computer will be re-added to
the replica set. The re-addition will trigger a full tree sync for the
replica set. WARNING: During the recovery process data in the replica
tree may be unavailable. You should reset the registry parameter described
above to 0 to prevent automatic recovery from making the data unexpectedly
unavailable if this error condition occurs again. To change this
registry parameter, run regedit. Click on Start, Run and type
regedit. Expand HKEY_LOCAL_MACHINE. Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters" Double click on the
value name "Enable Journal Wrap Automatic Restore" and update the
value. If the value name is not present you may add it with the
New->DWORD Value function under the Edit Menu item. Type the value name
exactly as shown above.



On Mon, Jun 7, 2010 at 12:04 PM, Sebastian del Rio <
sebastiandelrio@gmail.com> wrote:

> Hi Al,
>
> First at all I would like to know if there is any FRS replication issue
> there, if you test to create a folder is that folder replicated to all of
> that DCs?
>
> If the replication is actually working fine , you can follow this
> instructions to match the version number , then force the replication to
> propagate the changes, check if has replicated fine and as last step , check
> if the GPOTOOL does not show the error anymore
>
> 1.Run GPOTool (from the Resource Kit) and get the output
>
> 2. On the PDC Emulator only: Open the GPT.ini file located under
> Sysvol/sysvol/<dom
> name>/Policies/ <Guid for Default domain pol>
>
> 3.Carefully change the Version number to match the version number of the DS
> from
> the GPOTool output
>
> 4.This should replicate within a short time.
>
> 5.Verify the replication by checking other DCs.
>
> 6.Make another small change to the policy and make sure the version numbers
> increment correctly
>
>
>
>
>
> On Mon, Jun 7, 2010 at 5:40 AM, Al Rose <arose107@gmail.com> wrote:
>
>> Hi everyone,
>>
>> Prior to upgrading our AD to 2008 R2 i would like to make sure about AD's
>> health.
>>
>> Running a dcdiag /q on my DCs gives an error:
>> There are warning or error events within the last 24 hours after
>> the SYSVOL has been shared. Failing SYSVOL replication problems may
>> cause Group Policy problems.
>>
>> Running gpotool
>> Error: dc02.eu.acme.com - AMSTERDAM-DC01.eu.acme.com<http://amsterdam-dc01.eu.acme.com/>sysvol mismatch
>> Error: dc02.eu.acme.com - wroclaw-dc01.eu.acme.com sysvol mismatch
>> Error: dc02.eu.acme.com - amal-dc02.eu.acme.com sysvol mismatch
>>
>> I have installed Ultrasound to monitor FRS but so far all lights are
>> green.
>>
>> Can somone point me to the right direction to troubleshoot the issue.
>> After a bit of googling i found that you can change manually the sysvol
>> version but i am not sure about consequences.
>>
>> Thank you
>>
>
>

sdelrioUser is Offline

Posts:14

06/07/2010 4:01 PM  
You have to do , what the event says :)

Expand HKEY_LOCAL_MACHINE. Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters" Double click on the
value name "Enable Journal Wrap Automatic Restore" and update the
value. If the value name is not present you may add it with the
New->DWORD Value function under the Edit Menu item. Type the value name
exactly as shown above.



On Mon, Jun 7, 2010 at 11:12 AM, Al Rose <arose107@gmail.com> wrote:

> Also i get a lot of this warnings on DC01:
>
> Event Type: Warning
> Event Source: NtFrs
> Event Category: None
> Event ID: 13508
> Date: 6/6/2010
> Time: 7:08:46 PM
> User: N/A
> Computer: AMSTERDAM-DC01
> Description:
> The File Replication Service is having trouble enabling replication from
> AMSTERDAM-DC02 to AMSTERDAM-DC01 for c:\windows\sysvol\domain using the DNS
> name amsterdam-dc02.eu.acme.com. FRS will keep retrying.
> Following are some of the reasons you would see this warning.
>
> Ώ] FRS can not correctly resolve the DNS name amsterdam-dc02.eu.acme.comfrom this computer.
> ΐ] FRS is not running on amsterdam-dc02.eu.acme.com.
> Α] The topology information in the Active Directory for this replica has
> not yet replicated to all the Domain Controllers.
>
> This event log message will appear once per connection, After the problem
> is fixed you will see another event log message indicating that the
> connection has been established.
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
> Data:
> 0000: d5 04 00 00 Õ...
>
>
> On Mon, Jun 7, 2010 at 4:09 PM, Al Rose <arose107@gmail.com> wrote:
>
>> Apparently i do have FRS replication issues.
>>
>> I have created a txt file under \\domain\sysvol\domain path and then i ran
>> frsdiag Propagation File Tracer. After more than 10 minutes, all DCs are not
>> getting the file.
>>
>> The frslog file contain:
>>
>> Checking for errors/warnings in FRS Event Log ....
>>
>> NtFrs 4/24/2010 11:37:40 AM Error 13568 The File Replication Service has
>> detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in
>> JRNL_WRAP_ERROR.
>> Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
>> Replica root path is : "c:\windows\sysvol\domain"
>> Replica root volume is : "\\.\C:"
>> A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to
>> read from the NTFS USN journal is not found. This can occur because of one
>> of the following reasons.
>> Ώ] Volume "\\.\C:" has been formatted.
>> ΐ] The NTFS USN journal on volume "\\.\C:" has been deleted.
>> Α] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk
>> can truncate the journal if it finds corrupt entries at the end of the
>> journal.
>> Β] File Replication Service was not running on this computer for a long
>> time.
>> Γ] File Replication Service could not keep up with the rate of Disk IO
>> activity on "\\.\C:".
>> Setting the "Enable Journal Wrap Automatic Restore" registry parameter to
>> 1 will cause the following recovery steps to be taken to automatically
>> recover from this error state.
>> Ώ] At the first poll, which will occur in 5 minutes, this computer will
>> be deleted from the replica set. If you do not want to wait 5 minutes,
>> then run "net stop ntfrs" followed by "net start ntfrs" to restart the
>> File Replication Service.
>> ΐ] At the poll following the deletion this computer will be re-added to
>> the replica set. The re-addition will trigger a full tree sync for the
>> replica set. WARNING: During the recovery process data in the replica
>> tree may be unavailable. You should reset the registry parameter described
>> above to 0 to prevent automatic recovery from making the data unexpectedly
>> unavailable if this error condition occurs again. To change this
>> registry parameter, run regedit. Click on Start, Run and type
>> regedit. Expand HKEY_LOCAL_MACHINE. Click down the key path:
>> "System\CurrentControlSet\Services\NtFrs\Parameters" Double click on the
>> value name "Enable Journal Wrap Automatic Restore" and update the
>> value. If the value name is not present you may add it with the
>> New->DWORD Value function under the Edit Menu item. Type the value name
>> exactly as shown above.
>>
>>
>>
>> On Mon, Jun 7, 2010 at 12:04 PM, Sebastian del Rio <
>> sebastiandelrio@gmail.com> wrote:
>>
>>> Hi Al,
>>>
>>> First at all I would like to know if there is any FRS replication issue
>>> there, if you test to create a folder is that folder replicated to all of
>>> that DCs?
>>>
>>> If the replication is actually working fine , you can follow this
>>> instructions to match the version number , then force the replication to
>>> propagate the changes, check if has replicated fine and as last step , check
>>> if the GPOTOOL does not show the error anymore
>>>
>>> 1.Run GPOTool (from the Resource Kit) and get the output
>>>
>>> 2. On the PDC Emulator only: Open the GPT.ini file located under
>>> Sysvol/sysvol/<dom
>>> name>/Policies/ <Guid for Default domain pol>
>>>
>>> 3.Carefully change the Version number to match the version number of the
>>> DS
>>> from
>>> the GPOTool output
>>>
>>> 4.This should replicate within a short time.
>>>
>>> 5.Verify the replication by checking other DCs.
>>>
>>> 6.Make another small change to the policy and make sure the version
>>> numbers
>>> increment correctly
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 7, 2010 at 5:40 AM, Al Rose <arose107@gmail.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Prior to upgrading our AD to 2008 R2 i would like to make sure about
>>>> AD's health.
>>>>
>>>> Running a dcdiag /q on my DCs gives an error:
>>>> There are warning or error events within the last 24 hours after
>>>> the SYSVOL has been shared. Failing SYSVOL replication problems may
>>>> cause Group Policy problems.
>>>>
>>>> Running gpotool
>>>> Error: dc02.eu.acme.com - AMSTERDAM-DC01.eu.acme.com<http://amsterdam-dc01.eu.acme.com/>sysvol mismatch
>>>> Error: dc02.eu.acme.com - wroclaw-dc01.eu.acme.com sysvol mismatch
>>>> Error: dc02.eu.acme.com - amal-dc02.eu.acme.com sysvol mismatch
>>>>
>>>> I have installed Ultrasound to monitor FRS but so far all lights are
>>>> green.
>>>>
>>>> Can somone point me to the right direction to troubleshoot the issue.
>>>> After a bit of googling i found that you can change manually the sysvol
>>>> version but i am not sure about consequences.
>>>>
>>>> Thank you
>>>>
>>>
>>>
>>
>

You are not authorized to post a reply.
Forums >ActiveDir Mail List Archive >List Archives > [ActiveDir] Running dcdiag /q before upgrading AD to 2008 R2



ActiveForums 3.7
Friends

Friends

VisualClickButoton
Members

Members

MembershipMembership:
Latest New UserLatest:MrPTSai
New TodayNew Today:0
New YesterdayNew Yesterday:0
User CountOverall:5234

People OnlinePeople Online:
VisitorsVisitors:53
MembersMembers:0
TotalTotal:53

Online NowOnline Now:

Ads

Copyright 2009 ActiveDir.org
Terms Of Use