2012r2 Update - SYSVOL Missing

Hi I am replacing my SBS 2003 with a Server 2012r2.

I have raised the domain and forest levels and have prompted the new server to a domain controller then transferred all the FMSO roles but when I browse to the new server it doesn't seem to have created the shares for the SYSVOL and NETLOGON shares.

Is there anything I can check to see why it hasn't done this?

I did remove the Global Catalogue tick from the NTDS on the old server (have put it back now) but not sure this would be why.

Any help would be great.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
Dcdiag is your friend. Those shares won't be created until the DC decides replication is healthy. Journal wrap and improper removed old DCs are common culprits.
RedDoorSuppliesAuthor Commented:
Ok thanks for that.

So to confirm the old SBS 2003 server (that I want to demote and turn off) is called primary and the new 2012r2 server is called S5Primary with S5Controls as the domain.

Ive done a dcdiag /a from the new server and posted the results in the attached file.

If you can have a look and see what I need to do that would be great.

I'm guessing I just need a onetime replication and then I can demote the old server?

Cliff GaliherCommented:
You've got several failures. Most are straightforward. Someone set services to disabled that shouldn't be, for example. Those are called out in the log. Your PDC is not running the time service (chances are someone disabled that too.)
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

RedDoorSuppliesAuthor Commented:
Ok thanks Ive started the services and then run the following

Go to WorkingDC  stop NTFRS service open regedit and go to "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" change the burflag value to D4 Start NTFRS(File Replication service) service and wait for File Replication event ID 13516 now Go to ProblemDC  stop NTFRS service open regedit go to "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at <samp>Startup" change the burflag value to D2 -> Start NTFRS(File Replication service) service and wait for File Replication event ID 13516 now

This has got the replication up and running.

Ive attached the dcdiag /a now can you see if there is anything else I need to worry about before demoting the old server as still have a few errors.

Many thanks
Cliff GaliherCommented:
You still have service and Tim failures and a server failing advertise. By fiddling with burflags, you forcibly got the new server up, but if replication was not complete and the server named in the logs is failing to advertise, data loss is a real possibility. Instead of addressing the old errors, it looks like you may have gotten or read done bad advice. Rushing into a bad fix I rarely a good idea.

At thus point, I no longer know what state your network is in and without a thorough site survey, would not B comfortable making *any* recommendations. You may want to consider hiring an AD specialist in your area now...
RedDoorSuppliesAuthor Commented:
Ok thanks the main reason for the change was that the 2003 server has been failing etc so need to get it out ASAP.

Will shut it down check the users can login ok then power backup and try and demote the server and see what happens.

Cliff GaliherCommented:
I understand.  Just be prepared that, even if users can log in, you may find machines reporting broken trusts that you'll have to unjoin and rejoin the domain, as well as password resets that may not have taken.  Again, based on what I'm seeing there and how burflags work, you still have one server failing to advertise, but forced the new one to think it is a viable DC anyways, even though *proper* replication may not have completed. Which means some objects may be missing or have stale information.  Usually this is not a major issue and workarounds (resetting passwords, unjoining/rejoining) can resolve the issues that creep up. But technically other things may also be missing depending on which containers didn't replicate and bigger issues could arise which is why I am wary to give advice. It *could* make a bad problem worse, just as we already have seemingly taken a minor problem and made it bad so far. If it were my network, I'd probably look at an authoritative restore of the old DC to get to a known good state and then restart from there. But if it is failing, I understand that may not be an option. Although I'd also say that this is a good indicator that you have a hole in your DR plan as well, since going back is apparently not an option. That may be a DR scenario you want to address once you are out of the woods.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RedDoorSuppliesAuthor Commented:
Thanks for all the assistance
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.