Will Migrating Print services DHCP and DNS from production SBS 2008 production to 2012 immediately affect users ?
I would like to migrate services from the SBS server 2008 to Server 2012 standard running on a hyper V
Have migrated exchange to 365.
Have added new server to domain
Have created new security groups
Would like to migrate dns
Migrate dhcp
Migrate and test print services
Migrate and test Remote Desktop gateway services
Setup new group policies using test desktop
Copy data from SBS
Setup permissions and test against policies etc
Then go live .
Demote SBS server
I need to do all this while the SBS is in production .
Is this possible ?
I am particularly concerned about the dhcp dons and print services being disrupted by another server on the network running the same services .
Also is there any instructions on remote gateway services out there .. Everything I see talks about something called essentials . Or migrating from 2003 to 2008
If you could point me to a comprehensive guide I would be grateful
Have migrated exchange to 365.
Have added new server to domain
Have created new security groups
Would like to migrate dns
Migrate dhcp
Migrate and test print services
Migrate and test Remote Desktop gateway services
Setup new group policies using test desktop
Copy data from SBS
Setup permissions and test against policies etc
Then go live .
Demote SBS server
I need to do all this while the SBS is in production .
Is this possible ?
I am particularly concerned about the dhcp dons and print services being disrupted by another server on the network running the same services .
Also is there any instructions on remote gateway services out there .. Everything I see talks about something called essentials . Or migrating from 2003 to 2008
If you could point me to a comprehensive guide I would be grateful
ASKER
That sound good and I like that approach .but doesnt SBS 2008 get unstable if you do less than a big bang ?
And if I run into problems migrating DHCP etc .. How can i revert back in a pinch so I can fix the mistake .
I am dealing with an environment where they can afford very little downtime . If for example I migrate printers and non of them work .. That will be a big deal .. If no-one can log into the server for an hour .. That would be a big deal
Almost any disruption would be a big deal
This is why I am trying to migrate .. run parallel ..test with non production desktop .. then move on .
And if I run into problems migrating DHCP etc .. How can i revert back in a pinch so I can fix the mistake .
I am dealing with an environment where they can afford very little downtime . If for example I migrate printers and non of them work .. That will be a big deal .. If no-one can log into the server for an hour .. That would be a big deal
Almost any disruption would be a big deal
This is why I am trying to migrate .. run parallel ..test with non production desktop .. then move on .
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In theory there's be no disruption and a big bang is possible. In practice there are always small glitches, forgotten settings, the "oh yeah, I referenced the server in *that* logon script" type things that you have to update when users report the issue. By doing one at a time, knowing what broke and why becomes *much* easier. A user may forgive a printer disappearing for a day. They'll be mad if they can't access their files, or the internet, or email, or print all at once because you tried to move *everything* and half of it broke.
You usually don't need or want to migrate a gateway. In 2012, the architecture has changed enough you will usually just stand a new one up, run them side by side, then update your port forwarding at the network edge when you are ready to cut over. So you won't find many, or any, "migration" documentation. RDG is a rather simple role with no real settings to migrate in most cases.