Dead DC - what to do about user profiles?

seedubya

seedubya

Well-Known Member
Reaction score
1,019
Location
Carlow, Ireland
New client. Can't get hold of the regular IT guy. Their server died and it turns out that the cloud backup that they thought was capturing everything was only capturing data - no image, no system state or anything AD related. They've only got 11 users so not too big a deal to set up a new AD.

They had roaming profiles set up to capture all the Desktop\Documents etc. in the server backup and I have the data. How can I migrate their existing profiles to the new AD with as little effort and disturbance as possible?
 
Were they actual roaming profiles or simply redirected folders? That may make a difference.

We use redirected folders for a bunch of stuff, and for that it's really just going to be a case of copying the folders and mapping appropriately (with appropriate permissions) on the new domain.

If it's actual roaming profiles, I'm not sure exactly how they're stored and whether Fab's would be able to do anything with those or not.
 
As far as I can tell it was roaming profiles but I'm open to correct. The box was Server 2008 SBS R2 and the profile information was stored in a folder called "Profiles". There also was a folder called "Redirected Folders" containing nada.
 
SBS...yikes....there's usually a LOT more than just shared data there. Exchange (email) being a biggie. Sharepoint users?
Stop 7B is a drive controller error...could try a few different modes there for the drives

Anyways, the direct way....do whatever means is necessary to crack open the drives and browse them (shouldn't be hard if you have them in VHD format). Copy the Profiles directory..along with everything else, shared data, etc. It would be best to get a big disk...format it FAT32...and copy all the data to it. This will "drop" all of the NTFS security quirks. (ownership, permissions, etc).

From the workstations, hopefully the local Administrator account is known? I can't stand walking into a network in this scenario where the prior tech never secured the local Administrator account. I feel like clubbing them over the head with a telephone pole a half dozen times. Hopefully the domain user accounts are members of the local admin group and you can enable the local Administrator account if it's not, or go and change the password of it if it's not enabled and you don't know what it is.

I'd pull the workstations to workgroup mode (unjoining the domain).
Copy each users profile that you pulled from the server to some local slush folder, like C:\Download.

Once you have your new server built, running as a DC, join it with the workstation as domain admin, reboot, log in as domain user, reboot...set user to local admin group, reboot...log in...set their account as local admin if you want, log out, log in as admin, and copy the users old profile folders to their respective new homes. (or you don't have to log in as admin for that, you can copy 'em over from the server via \\workstation\c$ just copying and pasting from the \\workstation\c$\download\blah blah folders to \\workstation\c$\users\username\blah blah

Flush out the old GPOs...often there a few that always linger...
 
YeOldeStonecat said:
SBS...yikes....there's usually a LOT more than just shared data there. Exchange (email) being a biggie. Sharepoint users?
Stop 7B is a drive controller error...could try a few different modes there for the drives

Anyways, the direct way....do whatever means is necessary to crack open the drives and browse them (shouldn't be hard if you have them in VHD format). Copy the Profiles directory..along with everything else, shared data, etc. It would be best to get a big disk...format it FAT32...and copy all the data to it. This will "drop" all of the NTFS security quirks. (ownership, permissions, etc).

From the workstations, hopefully the local Administrator account is known? I can't stand walking into a network in this scenario where the prior tech never secured the local Administrator account. I feel like clubbing them over the head with a telephone pole a half dozen times. Hopefully the domain user accounts are members of the local admin group and you can enable the local Administrator account if it's not, or go and change the password of it if it's not enabled and you don't know what it is.

I'd pull the workstations to workgroup mode (unjoining the domain).
Copy each users profile that you pulled from the server to some local slush folder, like C:\Download.

Once you have your new server built, running as a DC, join it with the workstation as domain admin, reboot, log in as domain user, reboot...set user to local admin group, reboot...log in...set their account as local admin if you want, log out, log in as admin, and copy the users old profile folders to their respective new homes. (or you don't have to log in as admin for that, you can copy 'em over from the server via \\workstation\c$ just copying and pasting from the \\workstation\c$\download\blah blah folders to \\workstation\c$\users\username\blah blah

Flush out the old GPOs...often there a few that always linger...
Click to expand...

Thanks Brian. Yeah, this is pretty much what I figured i.e. no really easy way to do it or script it, just roll the sleeves and go. Luckily, at least, they had long DHCP leases so they can still log on. I exported all their Outlook profiles last night and migrated them to Office 365 for email so Exchange is out of the picture. New server arrived this morning. No Sharepoint, thankfully. I spent ages fluting around with the 7B error but no joy so I just had to draw a line under that one.

Turns out the previous tech wasn't returning their calls as he's taken a job and doesn't even have that number any more. I managed to contact him, it's a small town, and paid him to spend a couple of hours with me last night going over their setup. He'd been trying to get them on image backups for ages but the boss wouldn't make a decision. He's made one now!!! They lost 3.5 days x 11 this week and they're still operating well below 100% efficiency. In wages alone that's over €7k never mind lost sales, goodwill etc. I reckon his dithering has cost the company the best part of €20k excluding my fees and hardware.
 
Last edited:
Just curious..what was the old server hardware? And RAID controller model?

What caused the original failure? What it hardware like a mobo that tanked? Or the server itself had a corrupted system volume and couldn't boot up?

I'm just curious what scenario this came out of....I've done a lot of P2Vs...never run across a stop 7b. Usually the old failsafe IDE will always let her boot up, as that's always already built into Windows. Doing some quick Google-Fu, there are tricks you can do to get that going, crack open the VHD, ensure certain baseline drivers are in there (like intelide.sys), and even crack open the registry and force it to use that.

Granted...likely a lot of time spent to resurrect a server that is likely too dead anyways, but sometimes just out of curiosity to experiment so you can try it the next time you run into this situation.
 
When you have roaming profiles, isn't a copy stored locally each time you log off the network? In the Windows\CSC directory? Can you do anything with that?

Edit: There is a GPO you can enable to stop this behavior, but by default a local copy is saved each time a user logs off.
 
The problem with roaming profiles is that they are tied to the login since the actual AD wasn't backed up and user accounts will be recreated that link is broken the existing profiles on the PC they use and the existing data on the server will not be recognized by the new AD accounts. They data within the old profiles will need to manually be migrated you might can script something that will help intelligently match the new and old profiles to copy data for you.
 
https://1drv.ms/u/s!AkYr1ddI8vEhgYBAp75CRyHoR2BuFQ

That VBS script will fix that 7B Error for you provided Windows has the drivers for generic boot devices installed. Ie; you'll need RAID Drivers if it's RAID.

Code: 
Remember the script asks for Windows Drive, not Windows Folder.

If it says access denied, you most likely pointed it to a driver folder that it does not have permission to read.

When pointing the script to a folder with drivers, point the script to an empty folder
if you do not have a specific driver.
 
I've had good luck using the P2P Adjust OS wizard in Paragon Hard Disk manager to get images to boot in a VM. Also sometimes if the BCD is messed up you have to boot into a PE/Install DVD/Dart/etc and rebuild the bcd, etc to get it to boot.
 
You must log in or register to reply here.

Similar threads

HCHTech
Hot-Desking setup
Replies
0
Views
600
HCHTech
HCHTech
HCHTech
How to screw up with class - :-)
Replies
5
Views
1K
HCHTech
HCHTech
JoelM
Untangle With New Server
Replies
7
Views
2K
trevm999
trevm999
HCHTech
Remotely configuring new DC-VM to replace existing physical DC
Replies
2
Views
999
YeOldeStonecat
YeOldeStonecat
I
Domain user profiles
Replies
7
Views
2K
timeshifter
timeshifter
Back
Top