Windows 2000 in-place upgrade to 2008 R2 problem.

W

Wernerm

Member
Joined
Apr 16, 2012
Messages
16
Reaction score
0
Hi everyone.

I recently did a in-place upgrade migration from windows server 2000 to windows server 2008 R2. I have not demoted the 2000 machine, because I'm having a problem that I just can't solve.

When I run the command "echo %logonserver%" on a clients workstation, it tells me it's still logging onto the old DC and not the new one. All the FSMO roles have been transferred, and I thought there was a problem with the DNS, but everything seems to be okay.

The old 2000 DC has a single-label DNS name, I'm not sure if this is the issue.

If anyone has any sort of idea what I can do, I'll be grateful. It's been a week, and I haven't resolved the problem. It's a tad stressful because the old DC is busy falling over, and I'm scared one of these days it's not going to come up anymore.

Kind Regards,
Werner
 
Are the netlogon and sysvol folders shared on the DC? (the new one)


In-place upgrade from 2000 to 2008R2 is not supported by MS....

Did you add a 2008 R2 DC to your existing domain? (which should be added to a 2003 domain after the 2000 domain was upgraded to 2003, less problems that way)
 
Last edited:
Are the netlogon and sysvol folders shared on the DC? (the new one)

No, not yet. How would I go about doing that? Should I just enable domain user rights?

In-place upgrade from 2000 to 2008R2 is not supported by MS....

Did you add a 2008 R2 DC to your existing domain? (which should be added to a 2003 domain after the 2000 domain was upgraded to 2003, less problems that way)

True, but I prepared the old DC for the 2008 environment, which makes it possible to do an in-place upgrade. See the link here: http://technet.microsoft.com/en-US/library/1d502209-cdb9-4e13-9a6c-57ad6c9d1e8b.aspx

Thanks a lot for your reply. I appreciate it.
 
Wernerm said:
Are the netlogon and sysvol folders shared on the DC? (the new one)

No, not yet. How would I go about doing that? Should I just enable domain user rights?

In-place upgrade from 2000 to 2008R2 is not supported by MS....

Did you add a 2008 R2 DC to your existing domain? (which should be added to a 2003 domain after the 2000 domain was upgraded to 2003, less problems that way)

True, but I prepared the old DC for the 2008 environment, which makes it possible to do an in-place upgrade. See the link here: http://technet.microsoft.com/en-US/library/1d502209-cdb9-4e13-9a6c-57ad6c9d1e8b.aspx

Thanks a lot for your reply. I appreciate it.
Click to expand...

The netlogon and sysvol folders should be shared automatically by the DC, if not then somewhere there's a problem.

Every DC in a domain shares those two folders by default, or at least starts sharing them when netlogon and FRS services starts...

Could be that there is a replication problem so it's waiting for FRS (replication) to finish before it shares it (Usually DNS is the culprit if there are replication issues), but I've seen this before a few times and had do manually fix it....
Google "missing netlogon and sysvol shares" plenty of ways how to try and fix it. I can't remember which worked for me the last time....

What errors/warnings do you have in the event logs regarding RFS or anything else to do with replication maybe?
Or something like: bla bla bla is preventing this computer to become a domain controller bla bla bla...

Also run dcdiag on both
 
Last edited:
Also, is your AD Sites and Services setup? ie IP ranges added to your site/s?
 
Please do a system state backup before attempting any of the resolutions.
 
What errors/warnings do you have in the event logs regarding FRS or anything else to do with replication maybe?
Or something like: bla bla bla is preventing this computer to become a domain controller bla bla bla...

You hit the hammer on the nail with that one, I'm receiving FRS errors. I rectified the AD and DNS errors, but I'm not sure how to go about rectifying the FRS errors. Take a look, I've posted a link below. I'm going to google it, but perhaps you might know a solution.

https://skydrive.live.com/redir.aspx?cid=b4e9cdfc06405de3&resid=B4E9CDFC06405DE3!140&parid=B4E9CDFC06405DE3!107&authkey=!AMngf0rxQPJZlww

Thanks a lot for your reply.

Kind Regards,
Werner
 
Last edited:
I'm getting hectic FRS errors on the old DC:

"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:\winnt\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.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] 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.
[4] File Replication Service was not running on this computer for a long time.
[5] 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.
[1] 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.
[2] 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."

I'll be looking into that, and let you know if I find anything.
 
Wernerm said:
I'm getting hectic FRS errors on the old DC:

"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:\winnt\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.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] 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.
[4] File Replication Service was not running on this computer for a long time.
[5] 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.
[1] 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.
[2] 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."

I'll be looking into that, and let you know if I find anything.
Click to expand...


Jip, you can try that registry fix, hopefully it solves it...
http://social.technet.microsoft.com...S/thread/ce62f0ed-5d8a-4c68-b5ff-b562ffdb17d1


Edit: also disable any anti-virus on both just to make sure...
 
Last edited:
Okay! I think I solved my issue!

I fixed the FRS errors, the two servers seems to be replicating now, however when I ran the "echo %logonserver%" command on the workstation, it reported that it's still logging onto the old domain. Here's where it gets interesting.

I stopped the netlogon service on the old DC, and rebooted the workstation. When the workstation logged on and I ran the command again, it logged onto the new DC. Now its never done this before, so I obviously did something right... So I'm happy about that.

I'm not sure why, I mean, the new DC is the operations master of all 5 FSMO roles, surely the workstations should log onto the new DC by default?

I'm going to run a couple of more tests, and if I'm satisfied with the results I'll decommission the old server and just pray that the machines log onto the new server lol.
 
Well, the pc will authenticate to any available AD server that falls under the same site under AD Sites and Services. If both your Domain controllers is sitting in the same site then it will authenticate to any one of the two...
Once you demote the old server it should only the new one left and it will authenticate to that one.

Are both servers on the same IP range, and clients as well? (Just asking because then you could(should) setup AD sites and services and create a second site for the new server (or old one)
 
Hey Shawn,

Thanks for your reply.

Both servers are on the same IP range but some of the users are on a different IP range. But just out of curiosity, I did a migration so by default both servers will fall under a default site. How would it be beneficial to create a new site for the new DC?
 
I suppose it would only be beneficial if you have two AD servers, both on different IP ranges, plus your clients on another range. That way you almost tell the clients which is the closest AD server to them. (This is only really important to implement if you have a AD server at another physical location and traffic has to go over a WAN (or any other slow) link.

Lets say you have 4 IP ranges: 10.1.2.0/24 10.1.3.0/24 10.1.4.0/24 and 10.1.5.0/24
AD Server 1 on 10.1.2.0/24, AD Server 2 on 10.1.3.0/24 and clients use 10.1.4.0/24 and 10.1.5.0/24
If both servers are under the default site, all clients will authenticate to both servers.
When you create a site in AD sites and services you also need to specify which subnets that site has. So lets say You add IP ranges 10.1.2.0/24 and 10.1.4.0/24 to one site, and add 10.1.3.0/24 and 10.1.5.0/24 to a second site.
What that means is clients on IP range 10.1.2.0/24 and 10.1.4.0/24 will authenticate to the server that is on the 10.1.2.0/24 range, and clients/servers on 10.1.3.0/24 and 10.1.5.0/24 will authenticate to the AD server sitting in the 10.1.3.0/24 range...

This is not really important to implement if all your AD servers are sitting in the same building all on a 1000Mb or 100mb network, but once you have a AD server that is sitting in another building and traffic has to cross a slow wan link you would rather want the clients to authenticate to the AD server on their premises and not let the traffic go over the WAN link...
If it does not find the server on the same subnet it will then try to authenticate to one in another site
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X