Some of you (NGWList members) may know that our company's direction was to dump GroupWise 7 and go with Exchange 2007. We’ve been using GroupWise since version 3.x, so it’s fairly entrenched. The rationale from our new management was somewhat sound on the surface – we were looking to expand our reach as a healthcare provider and begin to assist other entities with their IT needs and therefore we should flatten our technology. That also meant to reduce the amount of vendors we were using and depend on just a few for the bulk of our technology needs. Novell was being bounced out -the Novell client, GroupWise, IDM, NetWare and SUSE (server and client), just to name a few.
Let me describe our situation:
I work for a large hospital. That hospital has a support organization that acts like an umbrella corporation for a number of other hospitals. Since we are the 800lb gorilla in the room, much of the IT direction comes from us. Our GroupWise system is linked via our MTAs with two other external entities for address book and calendar sharing. We run GroupWise on NetWare servers, with the exception of our WebAccess needs, which run on Windows. The long term plan was to extend our systems by adding address books and calendar sharing with other hospitals running Exchange.
Seeing how I was the email guy (GroupWise), they sent me to HP's Exchange Academy (very intensive course), as well as a number of Exchange classes. If you are looking to go to Exchange, insist on attending the Academy after you’ve had a training class introducing you to Exchange 2007. HP Exchange support experts were there, giving us their knowledge. They even had the Exchange upgrade project manager give us his feedback on their server consolidation project.
We set up an Exchange 2003 server and two Exchange 2007 servers as a pilot. We deployed the Novell Exchange connector in the hopes of being able to have GroupWise talk clearly to Exchange. After a bit of tweaking, we were somewhat successful in doing so. Here are the issues we discovered:
- Busy search did not work with Exchange 2007 users. It works fine with Exchange 2003 users (just like Novell’s documentation subtly states).
- A rescheduled appointment creates a new appointment but does not delete the old one.
- The Novell connector had major issues in creating contacts properly, especially with our two external systems, until Novell revealed the hidden switch that allows Contacts to be created properly with the SMTP address.
- Users that we migrated over to Exchange were not reflected properly in the external systems and needed to be populated by hand. Essentially you’re moving a user from a visible source (Post Office) to a non-GroupWise entity, Exchange, which is not visible by other external systems that are tied into your email system. So in order to address emails to these people properly from those systems, the administrators on those systems would need to create remote addresses for these users to send email accordingly.
- The migration would have to be performed in a compressed period of time, regardless of the population size. If you have a way of migrating a single domain (we have a Post Office that has its own separate internet domain and does not use our domain), then migrate that one first as a test. The reason for the short period of time – calendar management would be a process that would need to employ both GroupWise and Outlook. Yes you can perform a rescheduling with the present setup. But not removing the old appointment is unacceptable in our mind. With some folks having 10-15 appointments a day, not removing the old appointment becomes a really big nightmare.
- In setting up the connector, we found that anything less than System for visibility did not get created as a Contact in Exchange. Take that for what it’s worth.
- We did have some issues with the emails coming from the Exchange users, through the gateway, were publishing all email addresses as user.postoffice.domain@domain. This caused a number of issues, including not being able to respond with GMS devices.
We then tried some live migrations of two users from GroupWise to Exchange (we did anchor the connector to an Exchange 2003 server) and found the migrations were spotty. One user lost an address book.
We then looked at a commercial migration package and found a tool by Quest. They require the Microsoft GroupWise connector, which uses the GroupWise 4.x APIs to move email back and forth. The main issue we discovered here after setting up the Microsoft Connector is that internet email was not around when that API was written, so incoming internet email was undeliverable. Quest had very little options, though they suggested we reroute our entire mail flow so that all Internet email would be delivered first to the Exchange server and if the user did not exist on Exchange, to push it over to GroupWise. Another idea that was suggested was to dump the email on the Exchange 2003 server and let it route the email using SMTP - that way, only the email that needed to cross the Gateway to get to Exchange would do so and the rest would be relayed to the GWIA.
We decided to approach management about these options, since this was a major change in our email design and its potential negative impact was huge (our existing Exchange customer base was 2, GroupWise was over 15,000). One discussion led to another, regarding money. The director in charge of the migration project had not budgeted any money for this year, nor had he budgeted any money for the next year. Oops. One of the nuggets that I took from my Exchange class that I received at HP was that for the best performance, we should deploy the 2007 client of Outlook. Yes, older clients work with Exchange 2007, but in addition to all of the features that you would not have by running an older client, there was a serious issue that we would experience here. If you move a user from one database to another, the client would not be able to auto-discover where the user got moved to, unless you were running Outlook 2007. Our plan was to migrate the folks over to Exchange 2007 and then we would probably have to juggle stuff around once we were in production. The cost attempting to make this upgrade to Outlook 2007 was huge!
My thinking also was that if I'm going to rip out the user's favorite application (also called here the company's most important application - GroupWise) and replace it with anything else, it needs to be significantly better, easier to use and come with a whole lot of extra jimmies. Unified Messaging, direct email synchronizing with a PDA, etc were some of the extras that we were considering giving during the rollout. If the company was not prepared to throw it all into the delivery, we were doomed to failure. In my previous work experience, I was part of a word processing migration project – Word Perfect to Microsoft Word. I know that you can’t please everyone nor can you work with each individual to ensure that they’re going to be happy with the decision you’ve made. The best you can do is to make the delivery of the replacement a shining success, couple it with end user marketing and training and follow-up after the fact.
Thankfully, our VP made the decision to pull the plug on the project and said that if it's budgeted for, down the road and if it makes sense, we should consider it again. We'll see. So we may be on GroupWise for some time.
My personal thoughts on Exchange 2007:
This application is sound and is a significant competitor to GroupWise. There are some features that it has that I would welcome in GroupWise – one of which is security for emailing to distribution lists – controlling who can send email to a list. Say what you want about the 64bit architecture and Exchange 2007 having to run on only 64bit – Microsoft had no choice. They had to rewrite the code for Exchange 2003, based on its performance. Exchange 2007 is a great product.
That being said, it doesn’t come cheap. You need to purchase 64 bit servers – you can’t get around that. You need to deploy different types of Exchange servers – planning is extremely essential – this requires more than a napkin for planning. You are going to buy servers with more than one processor – you will pay more for server licensing per processor. Chances are you are going to need more than 4 Gig of RAM, so you will need the Enterprise license for Windows Server (2003 or 2008). Training materials for the IT support staff and the end users are also going to be necessary for a successful implementation.
If someone says they’ve worked on Exchange before, unless it’s Exchange 2007, they haven’t got much experience to carry over. Exchange 2007 is that different. The management tool was completely rewritten and the powershell needs to be mastered. From the training I received from HP, the powershell is an extremely powerful tool and in most cases, far outpaces the GUI in functionality. Powershell needs to become your best friend.
My personal thoughts on the migration process:
- No matter how you slice it, the migration process cannot be spread over a long period of time. It needs to happen in a short burst. One of my colleagues at the HP Exchange Academy who did the migration from GroupWise to Exchange put it this way: “The migration is going to be painful, no matter how you do it, no matter how much training, testing and marketing is done. So get it done in as short as a period of time that you can. You won’t make friends during the process, but having it done in a compressed period of time shortens the complaint period.”
- Live Pilot testing – it may seem strange to state this – test with non-live accounts. I had two users who were drooling at the opportunity to be Exchange users. I turned my back and they had moved themselves over Exchange. One lost a personal address book in the process – boo hoo. They should have waited for extensive testing on a test user. We had a few test email accounts and were preparing to create a test user and import a 5 year old archive into the user for the purposes of testing the migration.
- Live Pilot testing – coexisting with GroupWise and Exchange is not meant to be a long term state. You’ll notice that GroupWise does not have a connector to Exchange 2007. Microsoft has no connector to GroupWise 7. Yes both products are fairly new. But both vendors rightly want you to migrate to their email system, not straddle the fence forever.
- Figure out how you’re going to support your external GroupWise customers that are tied into your MTAs. We did not spend an extensive amount of time in this area, but kept an eye on it. Users who get migrated on your GroupWise to Exchange disappear from the address book, from the viewpoint of those external GroupWise systems. So you and they will need to account for this.
- Proxying – this gets really ugly. You need to draw your organization out and draw a circle in pencil around the folks that you plan on migrating. Careful, don’t forget the administrative staff that supports those folks. Well, what about the administrative staff that covers for the first bunch? Circle them too. Now you’ll need to circle the staff they manage. See why you need to use a pencil? You’ll wind up circling your entire organization.
- Considering upgrading to Windows Server 2008 with Exchange 2007? When upgrading standalone servers, it is not supported to upgrade your operating system to Windows Server 2008 and then upgrade Exchange 2007 to SP1. It is also not supported to upgrade Exchange 2007 to SP1 and then upgrade your operating system to Windows Server 2008. To deploy Exchange 2007 SP1 on Windows Server 2008, you must install Windows Server 2008 on a computer that does not have Exchange installed, and then install Exchange 2007 SP1. For more info, go to http://msexchangeteam.com/archive/2007/08/16/44670...
- A cleaner migration path? You decide: Install an email retention system and archive all existing email and all GroupWise archives. Migrate all calendar info and swing email pipeline to Exchange servers. Users would have access to prior emails in the retention system and the migration period would be dramatically shrunken down.
- Not sure if it’s possible, but can you use the GroupWise client to access Exchange? This may also reduce some of the shock of the migration and let some folks gradually get used to Outlook.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.