How To Decomission A Single MS Exchange 2007 Server Post O365 Migration

Hello,

Back in July of 2017, we completed a cut-over migration to Office 365 hosted exchange; migrating from Exchange 2007.
We are using Azure AD Sync to keep user passwords and mail attributes synchronized with the cloud server.

So, now that we are no longer using our on-premise exchange server I need to know what to do to decommission it without breaking anything.

I have read through various tech-net articles on this topic, but I walked away from the articles rather confused.
I know that if we get rid of our on-premise exchange server, we lose the GUI interface for changing mail attributes, however the attribute editor in AD Users and Computers, and ADSI Edit are enough to get by on.

I guess what I am looking for is someone who has taken the plunge, and removed their local exchange server after a successful cut-over migration.

I would also like to know what steps you took from a high level to get this done.
cschmidt5Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

RoninCommented:
If you decide to remove Exchange, then simply remove the mailboxes in DB if there are any, delete PF, delete mailbox database.
Go to control panel, add/remove programs, uninstall Exchange, simple as that.
You do aware that editing attributes without Exchange is NOT supported, right? If you get yourself into problems with attributes, etc. Microsoft might refuse to provide any help.
0
cschmidt5Author Commented:
So, your comment about MS not supporting the use of the attribute editor reminded me of something else -

I had read that it is possible to get just an exchange management console installed somewhere - then we would still be supported by MS.

What would I need to do to get rid of the on-premise exchange and then install a newer version of the exchg mgmt console?
0
RoninCommented:
Let me put it simply.
Without installation of Exchange server on-prem, changes to mail-related attributes that are replicated to Office365 are NOT SUPPORTED.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Sandeep KumarAssociate ConsultantCommented:
The Decommissioning Exchange Server is a process to detach user mailboxes and public folders after upgrade or switch from one environment to another. Details are available at https://www.kerneldatarecovery.com/blog/decommissioning-exchange-server

To decommission Exchange Server 2007 visit steps and process here
0
cschmidt5Author Commented:
Ronin, you latest response seemed only slighty rude. Your initial response was not at all complicated or hard to understand, and I am not a simpleton.

My problem is this: I am getting mixed info from various sources, plus a lack of experience managing exchange.

Furthermore, I opened a case with the MS O365 team, and they said using the attribute editor IS supported.  However, this was coming from an outsourced "Over seas" team; should I trust them?  They work for MS...

When they told me that, it blew my mind, because I am aware of a particular technet blog that says "Not supported" just like you.

Additionally, the process you describe above for "Decommissioning" seems way too short, especially when I compare your procedure to this one:

https://blogs.technet.microsoft.com/mspfe/2015/08/26/decommissioning-legacy-exchange-servers/






That is why I am asking on EE, because I need to see what others have done in my situation.
0
RoninCommented:
Not sure where you see rudeness, directness - yes, rudeness - no.
I'm a direct person, I cut to the chase, you might be not. It's all matter of perception. Also, I'm not writing a novel trying to show the plot and explain all the sides of the story, it's a technical matter, which in majority of the cases relatively straight forward, in terms of solution.
Therefore I don't see need to spill too much "water".

Here couple of other articles I reply with when asked what to do if mailboxes are being migrated to Office365. I highly recommend reading through them.

Office 365 and Dirsync: Why should you have at least one Exchange Server on-premises
https://blogs.msdn.microsoft.com/vilath/2015/05/25/office-365-and-dirsync-why-should-you-have-at-least-one-exchange-server-on-premises/
 
How and when to decommission your on-premises Exchange servers in a hybrid deployment
https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

As you can see, by the date on the first one, it was published in May 2015, where the one you posted was published in August 2015. Also, as fast as I read through it, I didn't see anything mentioning Directory Synchronization, which applies to your case. (Important point to consider)
However the second one, was updated in July 2017 and it provides quite a different picture on the subject and states different stance on lack of Exchange in the organization while maintaining Directory Sync with Office365.

I can't tell you if you should or should not trust the "overseas" team. That's up to you.
But you might have guessed the answer after reading the articles.

I didn't provide any details on the process, only the high-level steps, due to the fact there are literally thousands of articles on the web on how decommission Exchange.

Now, if I would be in your shoes, I would NOT remove Exchange.
I would install the latest available version to be able to maintain Hybrid connectivity, if required and at least be able to edit users' attributes if you don't want/need Hybrid.

I personally would configure Hybrid, why? Because Hybrid Exchange serial key is free, whereas if you don't maintain Hybrid, you would need to pay for the Exchange license, that way or another. (Note, Exchange 2007 is NOT possible to configure Hybrid with Office365, only 2010 and up).

So, here's what I would do:
1. Deploy Exchange 2013 on the new server (the latest available to coexists with Exchange 2007).
2. Move everything to it, whatever you still have on 2007.
3. Decommission and uninstall 2007 from the environment completely.
4. Deploy Exchange 2016 on the new server.
5. Move everything to it, whatever you still have on 2013.
6. License the server using Hybrid key and get it connected to Office365 using Hybrid Configuration Wizard. (You can do the same with 2013, but why not to use the latest version?)
7. Happily live ever after ... updating Exchange 2016 with the latest CU every 3 or 6 month.

The only thing that you pay in Hybrid scenario is a Windows Server license as well as whatever price there's for the hardware/virtual instance.

An idea:  There are a lot of small factor systems (if you really short on hardware resources) that might be able to support hardware requirements for Windows Server + Exchange 2016. You probably not even need a "regular" server.

Since this "Hybrid" server doesn't hold any roles and simply used for management of users' objects, even if it dies, you use the recovery process, re-run the HCW and you back in business.

I hope you happy with making me write all this "novel" :)
1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cschmidt5Author Commented:
Ronin, sorry for misunderstanding.  I appreciate your time, thanks for the quick replies.
0
RoninCommented:
My above comment lacking part of decommissioning Exchange 2013.
That should be performed once you have everything on Exchange 2016.
1
cschmidt5Author Commented:
Thanks again kind sir
0
cschmidt5Author Commented:
Sorry, one last question, apologies if it is addressed in the articles; should I bother keeping all the old mailboxes?  Looks like I have to because if I start deleting mailboxes it trashes the AD accounts as well.  Can you tell I am not experienced with Exchange?  haha
0
RoninCommented:
I don't think so really, you already moved them to Office365 and it's happily working as much as I understand.
So, perhaps for backup purposes only. You should disable the mailbox instead of deleting, which delete the account and marks mailbox as disabled, which eventually (30 days by default) will be removed.
Glad I was able to help.
Thanks for accepting the answer.

Let me know if you have any other questions.
0
Todd NelsonSystems EngineerCommented:
Cutover migration, right?

Do not delete the mailboxes. Disable them.  The former will remove the associated AD user object.  The latter will disconnect the mailbox from the user.
0
cschmidt5Author Commented:
Hi Todd,

Yes, we did a cut-over migration to office 365.  So now I have a bunch of old mailboxes tied to user AD objects...I was hoping I wouldn't have to hang on to these data any longer, and reclaim the space.  Plus it is weird having these mailbox objects, knowing they also exist on the hosted solution.  

However, now that I know we can just spin up a new "Server" and move exchange over, it doesn't seem that difficult to move on.

I guess some of my confusion was caused by not knowing if we could go from our cut-over solution back to a hybrid solution.  We hired an outside company to help us with the migration; and I wasn't even involved in any of the planning up front. My boss just pulled the trigger and then had me help on the cut-over day.  I am not even sure if he asked the questions I am asking currently, all of this would have been good to know before we moved forward.
0
RoninCommented:
So, Exchange server is still under impression that mailboxes are connected to user account in AD, since it's not aware of Hybrid configuration, that would stamp the user objects with REMOTE attribute pointing to the cloud. The REMOTE (or whatever the correct name for it) attribute should be introduced (or populated, if it exists today) once you run HCW, however it might be dangerous due to the fact it will see that the HCW was not run before and might cause some unforeseen circumstances, basically clearing out that attribute.
Given I understand this correctly.
Before proceeding with HCW, I would investigate what would be the result of running it in the environment in which mailboxes have been already migrated to Office365.
Since you have Office365, you might want to inquire with MS support about it.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Office

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.