Removing RM CC4

[Andy2789]

I have recently been appointed with the responsibility of trying to turn the school network around. Currently the school is running RM CC4 which is strangling every element of the system and causes outages randomly. Staff and students are completely disengaged with IT as they have zero trust in the reliability of the network, which in 2018 is somewhat of an issue! This isn't my first rodeo taking a failing network and having to turn it around, however this is my first contact with RM... and my last!

 

I have ordered new servers, as there is zero virtualisation and the highest spec'd server currently has 4GB of RAM. Which is meant to be providing an infrastructure to 1100 users...

 

RM have been given notice of termination and I am in the process of building a new vanilla network without RM, I have built all my Group policies and starting to build my new server environment.

 

Does anyone have any top tips, or secrets I need to be aware of? All Servers that currently have RM on will be removed from the environment with new DC's taking over. However does RM leave anything behind or effect Active Directory in anyway?

Edited March 6, 2018 by Andy2789

[5tu]

Yes it does. You're much better off starting a brand new domain / AD and just migrating your data.

[Andy2789]

I knew someone was going to say that . My added issue with that is we use Office 365 with Azure Sync, so this could turn into a monster trying to merge data both on site and in the cloud if I build a new AD.

[synaesthesia]

Yup, been there and done that. Do it from scratch. Copy shared areas over if you like, maybe keep the same structure for things like staff shared, student shared and drive letters so people at least feel "familiar". Try not to dwell too much on what was there because there's so little that can actually be carried over.

[FishCustard]

For 'removing RM CC3/4' I would like to recommend 'tactical nuclear weapons', but I doubt your budget would stretch to that.

 

In all seriousness, create a new domain alongside and migrate. It's not worth trying to do it any other way - RM puts tentacles too deep into various things for the migration to go cleanly.

[5tu]

I knew someone was going to say that . My added issue with that is we use Office 365 with Azure Sync, so this could turn into a monster trying to merge data both on site and in the cloud if I build a new AD.

 

Yes that does make things rather more complicated! But I wonder if this might be a way forward.... https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-multiple-domains

[Norphy]

Sorry, I disagree. Rebuilding the domain from scratch is not necessary.

 

Yes, RM extend the AD schema but those extensions will be just unused with a vanilla network. @Roberto and I successfully migrated away from CC3 by building some domain controllers outside of the RM infrastructure, moving the users outside of the RM OUs and rebuilding the PCs. The CC software will be gone once the RM site servers are decommissioned. The domain is still up and working extremely well. The procedure would work with CC4 too.

 

The main reasons that I can see to NOT rebuild from scratch are either:

 

1) if your CC domain is using a non-routable domain suffix such as .internal or .local. Renaming domains rarely goes well in my experience so rebuilding it to have a more sensible domain name is entirely sensible

2) There is something demonstrably wrong with your current AD which can't be easily fixed.

 

Otherwise migrating away from CC while keeping your current domain is perfectly possible and sensible.

[Andy2789]

Thank you! That was my logic, I had looked into the AD schema's and couldn't see any core ones that RM had messed with. I have already started building my own OU's way from RM in a sensible structure along with new security groups from scratch. I couldn't see it pulling anything from the existing RM setup, so had assumed that if it wasn't in anything RM. RM isn't clever enough to know that it's even there!

 

Gradual migration and phasing out was my game plan, with a full rebuild of workstations over the Summer break. With a Apple Network and 365 I don't really want to build a new domain from scratch, I will build new DNS, DHCP, DC's and policies but the core AD I hope to retain.

[Norphy]

Plan it properly, document it and do things right out of the gate and you'll be fine. I'm happy to help if you have any questions, as is everyone else here.

 

In the interests of full disclosure, I'm also currently in the middle of a project to move away from CC4 as well. However, for me points one AND two apply to me so I'm starting from scratch. I can't even rename the domain because it hosted an Exchange instance once upon a time. It's a pain that I'd rather not have to deal with but hey, no more CC4 come summer!

[ITGURU]

Sorry, I disagree. Rebuilding the domain from scratch is not necessary.

 

Yes, RM extend the AD schema but those extensions will be just unused with a vanilla network. @Roberto and I successfully migrated away from CC3 by building some domain controllers outside of the RM infrastructure, moving the users outside of the RM OUs and rebuilding the PCs. The CC software will be gone once the RM site servers are decommissioned. The domain is still up and working extremely well. The procedure would work with CC4 too.

 

The main reasons that I can see to NOT rebuild from scratch are either:

 

1) if your CC domain is using a non-routable domain suffix such as .internal or .local. Renaming domains rarely goes well in my experience so rebuilding it to have a more sensible domain name is entirely sensible

2) There is something demonstrably wrong with your current AD which can't be easily fixed.

 

Otherwise migrating away from CC while keeping your current domain is perfectly possible and sensible.

 

I see no issues with having a .local or .internal domain. I've had a .local domain since day 1 and never had any problems even with always running Exchange , syncing with Google and O365 with no problems.

[Norphy]

ICANN are selling what were previously private TLDs so if you use .local or similar, you run the risk of using a public domain which isn't your property.

 

The biggest problem is that certificate vendors are no longer allowed to sell certs for non-routable domains so if you have a service which requires a publicly signed certificate (such as ADFS), your configuration is made more complicated.

 

Microsoft themselves strongly recommend that you don't use .local and .internal. Best practice is to use an unused subdomain in your public domain (so internal.domain.org for example).

[FN-GM]

I knew someone was going to say that . My added issue with that is we use Office 365 with Azure Sync, so this could turn into a monster trying to merge data both on site and in the cloud if I build a new AD.

 

I think you will be ok with this. As long as your usernames including FQDN suffix are identical on old and new it will be able to re-sync. I have converted a couple of schools from Office 365 only accounts to synced with AD and it worked fine when everything matched up.

[Norphy]

I think you will be ok with this. As long as your usernames including FQDN suffix are identical on old and new it will be able to re-sync. I have converted a couple of schools from Office 365 only accounts to synced with AD and it worked fine when everything matched up.

 

If you're moving from one domain to another and you're syncing with Azure AD Connect, you will need to turn off sync on the old domain. You'll need to wait for this to finish, that might take up to three days. Once that has done, the Office 365 users will be "converted" to in-cloud users. You'll then have to de-populate the ImmutableID from the Office 365 users as if you don't, when you try to sync the new domain it will come up with an error saying that these users are already synced from another domain.

 

I had fun with this when we stopped using Captia Openhive to manage our Office 365 and moved management in-house.

[Roberto]

Sorry, I disagree. Rebuilding the domain from scratch is not necessary.

 

Yes, RM extend the AD schema but those extensions will be just unused with a vanilla network. @Roberto and I successfully migrated away from CC3 by building some domain controllers outside of the RM infrastructure, moving the users outside of the RM OUs and rebuilding the PCs. The CC software will be gone once the RM site servers are decommissioned. The domain is still up and working extremely well. The procedure would work with CC4 too.

 

The main reasons that I can see to NOT rebuild from scratch are either:

 

1) if your CC domain is using a non-routable domain suffix such as .internal or .local. Renaming domains rarely goes well in my experience so rebuilding it to have a more sensible domain name is entirely sensible

2) There is something demonstrably wrong with your current AD which can't be easily fixed.

 

Otherwise migrating away from CC while keeping your current domain is perfectly possible and sensible.

 

Just to second this, we migrated a 3000 user domain away from RM/CC way back. The domain was set up on Windows 2000 with CC3 and the same domain is now RM-free and at the W2016 domain functional level with no issues.

 

It does take a bit of effort to untangle the RM stuff but less so than setting up a new domain (having done both in my time) and provided the domain is essentially well-run now and will be so in the future, keeping and tidying up is just fine. I've had no regrets. Technical reasons why a domain must be rebuilt are extremely rare. Certainly "it's a bit of a mess" or "there are one or two schema extensions we don't need now" are not reasons to evacuate an AD domain.

Edited March 6, 2018 by Roberto

[Andy2789]

Thanks everyone for their responses! Has put my mind at ease slightly that my slow and steady and build along side will work, without having to re-invent the whole environment! Much appreciated

[dbu]

Hi

 

I'm a tech in a school in Staffordshire, I agree with Norphy, we support quite a few local schools and have moved several away from CC4 without flattening and starting again. In all cases they have had .internal domains and sync happily with O365 after adding the domain suffix into the existing setup, some have had Exchange federated with O365 and others have just has the AD Sync tool with just O365.

 

All will be fine if you plan and test beforehand and once RM is out of your life you will be a happier person

[synaesthesia]

The biggest benefit by flattening a network from CC4, from personal experience is the absolute metaphorical feeling of having poured petrol over the old system and watching it burn whilst laughing like a stereotypical comic book villain.

[FishCustard]

The biggest benefit by flattening a network from CC4, from personal experience is the absolute metaphorical feeling of having poured petrol over the old system and watching it burn whilst laughing like a stereotypical comic book villain.

 

Can confirm, much cackling was heard in summer 2013.

[mrnoisy]

would anyone mind sharing the process they followed for this in more detail ?

[dbu]

Hi,

 

I will PM you my number if you want discuss it.

[PotNoodleTech]

When I did this a long time ago (to remove RM CC3) it was easiest to build up a separate new domain alongside on the same IP range and then when everything was ready, disabled DHCP/DNS etc on the old CC3 network, shut down the servers, enabled DHCP/DNS etc on the new servers (with same IP range etc) then rebuilt every workstation from scratch as RM leaves loads of crap on the PCs. If as part of your set up routine you use WDS/MDT as a build system then you should be able to build at least 3 it suites worth a day so it won't take long to convert everything over.

 

Also some of the money the sch used to pay RM can pay for things like Impreo to make management of the PCs much easier.

 

It's a big job but it's so worth it!

[Andy2789]

@AButters you have read my mind! I have new servers which are currently on the domain but away from RM, come the Summer I will enable DNS and DHCP on them and promote them to DC's and demote and remove the RM ones. We have built a new image using WDS/MDT and will re-image all the computers over the summer. Including migrating all the users and work over, we have used the money like you said and brought into Impero which we will use for management and safeguarding.

 

It's a lot of working and planning, but to get away from RM and its 80 odd applications it installs on every computer keeps me going!

[yac2016]

When I did this a long time ago (to remove RM CC3) it was easiest to build up a separate new domain alongside on the same IP range and then when everything was ready, disabled DHCP/DNS etc on the old CC3 network, shut down the servers, enabled DHCP/DNS etc on the new servers (with same IP range etc) then rebuilt every workstation from scratch as RM leaves loads of crap on the PCs. If as part of your set up routine you use WDS/MDT as a build system then you should be able to build at least 3 it suites worth a day so it won't take long to convert everything over.

 

Also some of the money the sch used to pay RM can pay for things like Impreo to make management of the PCs much easier.

 

It's a big job but it's so worth it!

This is what we a re currently doing, about 3 to do over half term, CC4 to brand new vanilla networks, all Windows 10 and Server 2016. I have always done it the same way as suggested here.

[PotNoodleTech]

Good work both!

 

[psydii]

Can confirm, much cackling was heard in summer 2013.

 

A few years ago I was hired to do something similar. Whilst trawling through the 2009 implementation paperwork (to figure out what came from where so I could rebuild it right), I found a copy of the resignation letter of the previous guy. To paraphrase:

 

 

Q2 2010.

I quit. Sorry. Buy iPads. Get out of the contract as soon as you can. Then hire psydii.

 

 

 

Which made me grin. To be honest I forgot I’d written that. #longtermplanning

 

 

 

Top tips: prioritise the software and services people need on the first day/week, the first month, the first term, the first year.

Read all the implementation documentation and plan how long each work package will take.

Schedule it.

But remember, once your users hit, you will mostly be firefighting.

 

 

Migration to the cloud is much easier now, so that may be an option for you if you have complete management buy-in.

 

Final point: if you can’t trust your switch infrastructure nothing will work properly until you do.

 

The danger with migrating away but keeping the domain and servers is that you bring across legacy practices that had no place in 1998 nevermind 2018. Don’t be afraid of a hard break to get rid of things like crappy file permission practices and the mixing of applications and user data.

Edited May 16, 2018 by psydii