Migrating from SBS2011 to Svr Std 2016

[HCHTech]

Is there a secret I'm missing here? I had one of these earlier this year for a small (6 users) customer. They were so simple, had already migrated to hosted exchange and only a single shared directory and no LOB apps. I decided to just setup the new server manually instead of doing a formal migration. Their SBS2011 box was having enough problems that I didn't want to risk carrying over any of that baggage.

Anyway, fast forward to today. Same basic scenario, small network, 7 users, 1 LOB app, single shared directory plus user directories, nothing complicated. For this one, we're moving from on-premise exchange to O365. I wanted to do a formal migration to a Server Standard 2016 box. We got the Exchange migration done last week ok, but the migration of the server today did not go as planned.

Basically, I was following the technet articles to the letter, but when I got to the point where I'm trying to make the new server a domain controller, the active directory wizard would not accept the network admin credentials, which of course made that step fail. Unfortunately, the failure message isn't verbose enough to point to anything in particular. Grabbing at straws, I even changed the administrator password on the new server to be equal to that on the old box, but of course that didn't help.

I could browse the old server on the network from the new server, but nothing I did would make the wizard happy. In the end after a dozen trips through the wizard to the same dead end, I ended up removing all of the roles from the new server and backpedaling with a manual setup again. More work and wasted time.

I found a step-by-step guides here and here during my prep, so I was pretty confident in my readiness - but that confidence was unrewarded, haha.

I know that SBS insists that it be the only domain controller on the network, maybe that's playing into the problem? If so, you would think that the migration tool would account for that.

I've done this successfully going from server 2008 to server 2012 a couple of times, but this is my first go round with SBS2011 as the source server. I've got three more of these coming before Christmas, so i'm hoping one of the seasoned wizards here can point me in the right direction.

 

[Markverhyden]

I've only once tried to migrate from SBS to Server Standard, '03 to '08. After some 30 hours, including using a swing server, I gave up and told them it had to be done manually. Since then pretty much everything I have read points to going from SBS to server standard to be full of pitfalls.

 

[OaksLabs]

Two things cross my mind:

1. Is this new server joined to the domain already (I'm assuming you're going to do a dcpromo here.... https://technet.microsoft.com/en-us/library/cc732887(v=ws.11).aspx )
2. Group membership: Your admin account will need to be a member of Enterprise/Schema/Domain...etc administrator groups (plain old domain admin won't quite cut it)

EDIT: I did a quick look at what your guides were doing. While the SBS might have some funkiness, I think your best bet is to add the new server to the domain, add it as a secondary domain controller, and then move the roles (see this article for some ideas: https://support.microsoft.com/en-us...nsfer-or-seize-fsmo-roles-to-a-domain-control )

It's normally another department where I work that does this dirty work, so I'm not an endless fountain of knowledge here. However, things should be in a good spot to clean up once the migration is done (you can track down GPOs, permissions, and AD issues that would give you issues).

 

[YeOldeStonecat]

I've done many SBS to full Server migrations...but I don't think I've done an SBS to 16 Standard before..or maybe just 1

I always do the approach OakLabs mentions.....I add the new server to the existing SBS domain, and then run DCPromo on the new server...making it a second domain controller. At that point I move over DHCP to it, reconfigure the network so the new server is the first DNS server on the network and the SBS box becomes second DNS server. Then shift over files, apps, printers....
Once it's "mostly" taken over the network, I'll shift over the FSMO roles to it. Only when SBS loses those roles...does it start the 21 day countdown to flipping out.

Domain functionality level raise up OK?

Sometimes you run into a quirk...who knows the cause, sometimes the "history" of a network can have an impact. Like this source SBS box got migrated in from an old server..migrated from another old server...the "active directory" could have gone through a few migrations in its past. Unknown if it was done properly, lazy prior techs skipping steps or whatever.

Properly migrating from SBS has a LOT of stuff that, sadly, many techs never do. Just removing Exchange from active directory takes a while..and really should be done. And then SBS has all those built in GPOs to mop up. And then it's funky OU setup in ADUC...you want to groom back to a more standard format.

So before I actually do a migration from SBS, I look at many factors. I'll migrate if things lie..the network is large and I have to do a migration with little or no downtime, after hours in lots of little stages.

If the network is smaller and I have available time and can interrupt them (like..it's not a 24 hour business)...I'm more apt to do a full cutover. (grab the data....pull workstations from old domain, make an all new domain and set it up like brand new).

 

[HCHTech]

It's possible I'm overthinking this, but I wonder if I screwed up with the accounts. When I did the OS install on the new server, I named the admin account 'Administrator'. No roles had been added at this point, just loaded all the drivers, & updates, and setup the networking. Then, when onsite, I booted up the new server and logged on with that Administrator account. It was from that account that I joined the domain, which already had an 'Administrator' user. Is it possible that this confused things? There were no errors, and I remember getting the normal prompt to enter an account that has permission to join the domain, but I'm just wondering if the two Adminstrator accounts butted heads somehow and that might have been where things went off the rails - it felt like a permissions problem.

I never got to the dcpromo part, both guides I was following had you do everything else first, then dcpromo as the last step.

Lastly, these guys had terrible DSL internet, so I couldn't do much before I was onsite. Had they had better internet, I would have liked to VPN to the network and do more of the job remotely. I could have certainly moved some of the data over. Just a thought.

 

[OaksLabs]

As far as your "Administrator" accounts go, I think it's a specification issue. As you know, AD accounts log on to the domain, and local accounts log on to that PC only (like home user PC's). You can have local accounts and domain accounts with the same name, which introduces confusion.

COMPUTER-NAME\Administrator is the account you created when you installed the OS. This account will not work for joining PC's to the domain, or for administrating any domain related items.

DOMAIN-NAME\Administrator is the domain admin that you need to use for the prompts you're getting for credentials. You can actually specify it in that format.

When entering credentials, the local accounts are used first. So, if you just entered 'administrator' it grabbed the local account with that name and didn't bother going out to check the domain for that account. the

domain\username

format should fix that.

[As bonus information, local accounts can be specified using

.\USERNAME

format.]

 

[YeOldeStonecat]

It's possible I'm overthinking this, but I wonder if I screwed up with the accounts. When I did the OS install on the new server, I named the admin account 'Administrator'. No roles had been added at this point, just loaded all the drivers, & updates, and setup the networking. Then, when onsite, I booted up the new server and logged on with that Administrator account. It was from that account that I joined the domain, which already had an 'Administrator' user. Is it possible that this confused things? .

That's a normal process, you build the new computer...as you build it it's in "workgroup mode". With its own local Administrator account.

You then plug into the network with the domain controller...it picks up the DCs IP for its DNS server....you run through the steps of joining the domain. When you go to join the domain, you'll get a challenge to provide credentials...you need to provide credentials of a user on the domain. Typically we provide a domain administrator account out of habit or popular convention. But technically you can use any domain user account unless the right to add computers to a domain has been removed from that account.

Some IT guys make the local administrator account on workstations the same as the domain administrator account.

When you join a domain and intend on using the domain administrator account and the password is the same on the local admin account, confirm the domain account by typing it in with that convention. domain\administrator for username.

 

[HCHTech]

Thanks, that's what I have always done in the past, but i was just looking for a reason that the it wouldn't transfer the roles after the domain was joined. I think you were right in your first post when you said something in the history was probably responsible. I don't know how it was originally setup in 2012. I've probably guaranteed myself a more trouble-free future by setting it up manually.

 

[HCHTech]

When entering credentials, the local accounts are used first. So, if you just entered 'administrator' it grabbed the local account with that name and didn't bother going out to check the domain for that account. the

domain\username

format should fix that.

[As bonus information, local accounts can be specified using

.\USERNAME

format.]

I didn't know about the shortcut for the local account, I've always just typed in the local machine name when I wanted the local account

MACHINENAME\Account

I've only replaced a handful of servers, but I've done hundreds of workstations over the years. Since I work with mostly small businesses, I'm one of those guys who creates a local account with the same name and password as the domain account. It's not best practice, but from a practical nature, it gives users admin access to the local machine, which allows them to install software updates & such. It's just not practical to do it the 'correct' way unless they have a tech-savvy employee who can be given the responsibility of those installs.

Edit: i'll bet the "dot" shortcut is carried over from DOS. in the CLi, remember "cd .." will go to the directory above the one you're in, and "cd ." give you the directory you are currently in.

 

[OaksLabs]

Since I work with mostly small businesses, I'm one of those guys who creates a local account with the same name and password as the domain account. It's not best practice, but from a practical nature, it gives users admin access to the local machine, which allows them to install software updates & such. It's just not practical to do it the 'correct' way unless they have a tech-savvy employee who can be given the responsibility of those installs.

That is one way to do it, and for your use case it probably works great. If you wanted to do a more locked down approach, you can create a group in AD, and then write a GPO to add that group as local administrators to whatever PC's you apply the policy to. Then all you need to do is add a domain user to the group, and they'll be a local administrator (on everything). A guide for this can be found here: http://www.dannyeckes.com/create-local-administrator-security-group-gpo/

 

[YeOldeStonecat]

I've only replaced a handful of servers, but I've done hundreds of workstations over the years. Since I work with mostly small businesses, I'm one of those guys who creates a local account with the same name and password as the domain account. It's not best practice, but from a practical nature, it gives users admin access to the local machine, which allows them to install software updates & such. It's just not practical to do it the 'correct' way unless they have a tech-savvy employee who can be given the responsibility of those installs..

The "Connect Computer" wizard of Small Business Server (the hand holding easy peasy setup method of joining a workstation to an SBS domain) has a checkbox for making the user a member of the local admin group. For standard servers without that wizard, it's really quick 'n easy to add the "domain users group" to the "local admin group" during that step of joining a workstation to a domain.

Even after the fact, you can control that via GPO.

Else you lose too much functionality that you really want from an administrative perspective, as well as functionality.