Maybe a fair while ago but if SIMS were not useable on 2008 R2 there would be absolute hell to pay ;)
I have to ask why people seem to think you need to create a new domain when doing a CC3 -> Vanilla migration. It's quite possible to remove CC3 while keeping your current domain.
Simply promote new DCs that don't have the RM components on them and remove AD from the old servers, and then create a new OU infrastructure for your workstations and users. Sure, you have to rebuild / re-create the servers that hold users home areas but then you're doing that either way.
That's all you need to do - its certainly all we're doing, and we've tested this quite extensively in both a virtual environment and - to some extent - on our live environment.
I'm not trying to tell people what to do here, but we're interested in why people seem to feel the need to do this as it seems like a lot of un-needed work.
I cant speak for everyone obviously, But the reason why im doing it like this is because a) I dont like our current domain its <schoolname>cc3.internal because we got a new domain when going from CC2.4 to CC3.2 (or so i am told) b) Because I think it would be easier to have a whole new domain and set everything up from scratch just in case of any RM AD components being left and finally c) I am looking to do a clean install on everything and currently we have 3 domains here and I would like to get them all into 1 nice domain so to speak, We have our CC3 one, SIMS one and an Admin one all set up before I arrived and so would like to merge it all into one so to speak.
RM components have a tendensy to stick around and you can never seem to remove it all, I tried virtualising our CC33 FRDC and tried to remove all the components and I got the majoroty of it off but it was very hard to remove and alot of the stuff sticks into the AD and so the best way I found was to demote the domain and get rid of it all together and then add a new domain in a new forest all together.
But that is just my reasons and to be honest its not that much work really I find it alot easier to do it that way anyway.
After going through the removal of CC3 last summer, i would advise putting all of your machines to windows 7 and not leaving any on xp it will decrease the amount of time and effort required for creating your gpo's. We are running some 7/8 ish year old rm towers on windows 7. They work fine after a ram upgrade from 512MB to 1GB.
A: Because a lot of people don't grok what CC3 has and hasn't added to Windows.Quote:
interested in why people seem to feel the need to do this as it seems like a lot of un-needed work.
There are a few RM AD custom attribute definitions etc. but they're completely harmless. The closest I've come to a genuine issue left behind by CC3 is a very occasionally 'wonky' set of security permissions on an RMMC created/managed AD user object (inheritance not ticked). Otherwise your points a. & c. seem reasonable.Quote:
Because I think it would be easier to have a whole new domain and set everything up from scratch just in case of any RM AD components being left
We plan on updating the schema yet again to 2008R2 level, move the FMSO roles over to a new DC then reinstall the CC3 servers to standard 2008 R2 units purely for hosting the user accounts.
If we had the cash to spend on a SANs, I'd just go down the route of creating a VM DC, but we're stuck with physical servers atm
We just done it last summer. Took around a week to setup all servers side, with DCs and GPOs, DHCP, DNS and so on. We have now 2 DCs and 2 file servers (that hold all docs etc), 1 sims server and WSUS+WDS server.
WDS is just such a big time safer in comparison to RM Build (we ditched that even before and used FOG). All was done from scratch, new domain and that transferred dns and dhcp roles and imported users through CSV files.
From old system I missed centralized console to create bulk users, assign software, printers etc. But those things can be done through other tools. Biggest pain were printers.
The print management on 2008 does not offer option for making printer default, GPPs were not reliable (the printers not always appeared) in the end we started using logon scripts and all is good.
I have to admit this was the best network move second to virtualization I have done here. Logon times are much faster, system can be customized to ours needs and we can use modern OS. And it is much cheaper to run. We saved 5k a year in support contracts and if we would like to move to CC4 it would cost us around £20k.
One advice, set up correct permission on home folders from the beginning, we had a bit of struggle with that.
Only what we left behind is smart cache, it is cheap to run and does what we need - no sense in reinventing wheel. It is just a linux with squid on it.
Best thing to do and I know I have done it... is to build the new vanilla network along side your existing network, once you've fully tested it and are happy with things slowly move blocks of PC's over to the new domain. You'll see then how things are working and if you've missed something.
Use things like WDS And Deployment Workbench and GPO for your policies it's easy once you start getting to know all the tools, then like I say move over blocks of machines we did 10 machines at a time, users can still work on CC3 or Vanilla doesnt matter what machines they use aslong as you copy over all the settings and iles/folders to the new accounts on the new domain.
Setting up a whole new domain is certainly cleaner, and as others have said, RM components have a habit of hanging around and/or making unexpected changes. Also, RM does a lot of config through RM Workstation Delivery and RM AppAgent so you'd need to create those settings anyway. Also, as cpjitservices says, it allows you to run both networks side-by-side for transition purposes, allowing the network to remain live throughout if you so desire.
What I will say is this - go into the AD on your CC3 server and have a good look at how RM have set it up, especially if you're not that clued up on AD, GPOs, etc. No harm, to be honest, in backing up all the RM GPOs in case you wish to restore them into your new network. Kind of wish I did that here before migration.