Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 761
  • Last Modified:

Does sysvol migration in windows 208 R2 DC, requires any specific steps, if the AD Data are stored not in C drive of the server?

With one of our client, the windows 2008 R2 Active directory data are stored on D drive of the PDC (NTDS DATA, NTDS Logs and SYSVOL) and on the other 2 Dcs, they are on different drives too.

So my question when we do the sysvol migrations to DFS, do we have to add any specific command or script other than the usual migration commands?
0
Zacharia Kurian
Asked:
Zacharia Kurian
  • 10
  • 4
  • 4
1 Solution
 
David Johnson, CD, MVPOwnerCommented:
Why in the world did they move the sysvol folder.. it is normally located in C:\Windows\Sysvol and moving it means changing the registry, editing junction points. editing active directory using adsiedit ....

A migration SHOULD read these locations and update it properly but you can only test to be sure.. Many, many programs break when you use non default locations.
0
 
Zacharia KurianAuthor Commented:
Has some one come across a situation like this?

The reason why the customer has done so, is that they around 2300 users in their network and they say they pretty lots of AD objects. So they were more of "space" concerned on their AD servers.
0
 
Zacharia KurianAuthor Commented:
we just checked the status FRS of SYSVOl by running the tool FRSDIAG and it passed the test on their 3 DCs. They do not have ROD in their network.

I am still waiting for some one help with my above question.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
DrDave242Commented:
Why in the world did they move the sysvol folder.. it is normally located in C:\Windows\Sysvol and moving it means changing the registry, editing junction points. editing active directory using adsiedit ....
Not necessarily. You can specify a non-default path anytime you promote a DC. 99.999% of admins (myself included) probably click right past that, but the option is there.

Zackur, as long as your client specified the non-default SYSVOL path during promotion or followed the supported procedure for relocating it afterward, the migration shouldn't have any problems with it. According to this thread, the new SYSVOL path will be on the same volume as the old one.
0
 
Zacharia KurianAuthor Commented:
Thanks DRDave242,

We will do the procedure in the coming Thursday night. We go the permission to do so at night and they have already taken precautions like backup, and rescheduled some of their routine procedures in the network. Also they  have notified their users that a migration is been scheduled.
I will notify you all about the results on  coming Saturday .
0
 
Zacharia KurianAuthor Commented:
sorry for not properly studied the situation.

The 2nd DC of the customer, the IT guy did something very strange. The drive letters of PDC and the 3rd Dc is on "D" but the 2nd DC, the drove letter is "E" not D.

Will this be an issue?
0
 
Zacharia KurianAuthor Commented:
here is more details;

When we went through the disk management of the 2nd DC, the drive letter "D" is not assigned to any of the partitions. It has only 2 partitions C & E, where "E" has all the SYSVOL ,NTDS etc..

If we re-assign the letter "D" for the current "E", will it solve the issue?
0
 
David Johnson, CD, MVPOwnerCommented:
Don't change the drive letter you will mess things up completely.

It is already in the registry under those drive letters and locations.
0
 
Zacharia KurianAuthor Commented:
so I can proceed with sysvol migration without changing the drive letter of 2nd DC?
0
 
Zacharia KurianAuthor Commented:
or can I really change the drive letter if I do the below steps;

1. Take backup of the 2nd DC.
2. Copy the entire "E" drive where they have all the sysvol, NTDS Logs & NTDS Data.
3. Stop the  FRS.
4. Modify the FRSRootPath attribute & FRSStagingPath attribute using ADSIedit.
5. Modify the registry keys;
           (a) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters
                   SysVol"="E:\\AD DATA Do not Delete\\SYSVOL\\sysvol
                                 to
               SysVol"="D:\\AD DATA Do not Delete\\SYSVOL\\sysvol

     (b) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
                 BurFlags value = D2
And finally restart the FRS.

Will it work?
0
 
David Johnson, CD, MVPOwnerCommented:
safer to demote the DC and the promote it and wait for replication
0
 
DrDave242Commented:
Is there a pressing need to change that drive's letter from E to D? If it's not causing any problems as it is, I'd leave it alone.
0
 
Zacharia KurianAuthor Commented:
currently it doesn't cause any issues. But will it cause any after migrating the sysvol?

For the worst scenario case, I might demote the 2nd DC, which is a physical one and will create a VM guest OS in one of their esxi , using the same name and IP.

But yet I would like to know if we leave the drive letter as it is, will it cause any issues to the migration.

At the end what they require is AGPM, after migrating the sysvol.
0
 
David Johnson, CD, MVPOwnerCommented:
You say you are migrating.. from FRS to DFRS?  going from \\servername\sysvol to \\domain\sysvol ?
0
 
Zacharia KurianAuthor Commented:
Let me explain once again;
The customer wants two things:- 1. migrate sysvol from FRS to DFRS. 2 Then finally they want to have AGPM.

I have no issues in achieving AGPM. But has doubts about sysvol migration from FRS to DFRS, since their AD data is stored (SYSVOL, NTDS Data & Logs) on a different partition, escpecially the 2nd DC, where the datas are stored on "E" drive other than "D" on the PDC and 3rd DC.

What I have planned is to demote the 2nd dc where they have created the AD data on "E" drive. Then I would either promote it or create a new VM guest and will point the AD Data on "D" drive as same as the PDC and the 3rd DC.
0
 
DrDave242Commented:
You say you are migrating.. from FRS to DFRS?  going from \\servername\sysvol to \\domain\sysvol?
He's wanting to do this. SYSVOL will still be accessible at \\domain\sysvol just like always; it'll simply be replicated using DFS-R, which offers a number of advantages over FRS.
0
 
DrDave242Commented:
I don't have any personal experience with migrating a SYSVOL hierarchy that's stored in a non-default location, but since there are supported methods for relocating SYSVOL, I can't imagine it will cause any problems. This migration process has been around since Windows Server 2008, so if SYSVOL being in a non-default location caused problems with it, I can't help but think this would be pretty widely documented (and maybe even a hotfix released to address the issue) by now.

Obviously you'll want to back up the SYSVOL folder before beginning the migration, just in case something does go wrong.
0
 
Zacharia KurianAuthor Commented:
I would backup each dcs, their AD Datas for sure. Do not want to burn my hands!

It is bit strange that there is no proper MS tech note on migrating sysvol (FRS to DFS), if the AD datas are on a non default location. The reason why I am saying so is that, in many of the MS tech notes , they would state that "it is better or safer to store the AD data (NTDS & SYSVOL) on a different partition. At least this is what the IT guy at customer site said!

I will not do the last step in sysvol migration (eliminated state) unless make sure that the migration went well.

Please do wait for a couple of days and I will get back to you all with the result. I am sure this would be a case study for others.
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 10
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now