ShoreTel/MiTel: How to Migrate MiVoice Connect to a new Server

I have tried to move a few Connect systems from one piece of hardware/OS to another by doing a backup/restore  and it has always ended in disaster. There were always issues with CAS, or certs, or the client not connecting, that I ended up just telling customers it was better to build the system all over again on the new hardware and then cut over to it. Yes users would loose call history, voice mail, client settings extra but as I was not able to do it any other way and TAC was no help this was the best way to go.

With that being said, I did have a customer that had a UC 20 server running Server 2012 that had a bad HDD and needed to be replace. So we replaced with a UC 30 running Server 2016. I decided that this was a good time to try and see if I could make the migration work doing a export of the old server and the import of the new server. I was pleasantly surprised when i was able to get the import and everything working. So here are the steps that I took to make this happen.

The steps below assume that you have already installed all the server roles needed, and made the OS changes that Connect requires.

Also:

• This will change the server certificate for web services (Director,CAS)
• If you are using "Require secure client access" make sure to turn it off from Administration=>System=>Additional Parameters
• If you are using a 3rd party certificate, make sure you have the certificate and private key
• Make sure to install all pre-requisites and prep the server according to the Build notes and the Planning and Install guide
• Use the TACTOOLS power shell script to verify all roles and features are installed

On the Old Server

1. Back up System
1. Navigate to C:\Program Files (x86)\Shoreline Communications\Shoreware Server\MySQL\MySQL Server 5.0\Examples and run the following file
1. BackupCDR.bat -> Will output an .sql file to the root of C:
2. BackupConfig.bat -> Will output an .sql file to the root of C:
3. BackupWebridge.bat -> Will output an .sql file to the root of C:
1. Only required if there is an SA-100/SA-400 in use.
4. BackupMonitoring.bat-> Will output an .sql file to the root of C:
1. Only required for ShoreTel 14.x
5. Copy the resulting .sql files folder to a safe location (Network Share, Thumb drive, etc...)
2. Stop all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
3. Reboot the server
4. Copy the Shoreline Data folder to a safe location (Network Share, Thumb drive, etc...)
2. If the server is added to the active directory domain, delete the computer account from active director (Roll back from this is hard)
3. Shutdown the server or Disconnect it from the network

On the New Server

1. Make sure the new server has the same Name as the old server
2. Make sure the new server has the same IP address as the old server
3. Make sure the new server does not have any Anti-Virus
4. Add it to the domain if it is needed
1. Make sure there are not Group policies assigned to the server
5. Create a BLANK Shoreline Data folder and copy the keystore directory from the back up of the old server into the folder
6. Re-install the same EXACT version and build that was installed on the old server
7. Copy the database back up files to the root of the C drive
8. Restore all the databases with the restore.bat files located in the \Program Files\Shoreline Communications\Shoreware Server\My SQL\MySQL Server 5.0\Examples  or \Program Files (x86)\Shoreline Communications\Shoreware Server\My SQL\MySQL Server 5.0\Examples
9. Reboot the server
10. After the reboot, log into the server to verify that switches and phones are connected to the new server
11. Stop all ShoreTel services
1. C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
12. Copy the UserData, Prompts, IMArchives and VMS folders from the back up of the old server to the new server
13. Re import your 3rd party certificate through Director (if you have one)
14. Test the system thoroughly to ensure all system functionality is working properly
1. Workgroups
2. Route Points
3. Connect Client
4. Voicemail
5. Auto Attendants
6. Call Handling Mode Changes
7. Extension to extension dialing
8. External dialing
9. Dialing in to Workgroups, hunt groups, auto attendants
10. Phone time
11. Conferencing
12. Instant messaging
13. Call history
14. Mobility
15.  ECT
15. Request new system key

ShoreTel/MiTel: Auto Attendant at remote site with ShoreTel SG90V Switch not playing greeting

I ran into a issue just recently where I migrated a customer from a 2008 R2 server to a 2016 server and instead of doing a back up restore I configured the system from scratch. So it essentially is a new system running but with the same hardware and all the hardware had download the new configurations. The issue we ran into is that a remote site with a singe SG90V switch with external analog trunks would not play the auto attendant recording when some one would call in. It would just play the default ShoreTel back up auto attendant recording, no matter how we tried to route the call to the correct auto attendant.

We tried routing the call to a user and forwarding to the AA, we tried sending it to a route point and then the AA, we tried all sorts of things to try and make this work. The auto attendant was reachable if you called it internally, it was reachable if you called it externally at the HQ site, but the site it was supposed to work at could not get the AA to play. There were no communications issues, TMS was connected, LSP worked between the equipment everything seemed to be configured correctly.

It turns out that the customer uses Office 365 for voice mail to email, and the ShoreTel SMTP relay was configured to use port 587, it was using TLS, and had a smart-host configured as well as a user account to authenticate to Office 365 with. ShoreTel uses SMTP port 25 to transfer AA greetings to V switches, and because the customer  was using SMTP on 587 for Office 365 the recording could not be transferred to the V switch.

So to test we set the SMTP port to 25, removed TLS, and the user account, re-imported the greeting to the AA and tested. We were able to get the AA to play once this took place, but it broke their voice mail to email. This aspect is very important to them so we reverted the changes, but because the V switch already had the AA greeting saved the AA continued to work. The issue is going to be when they want to change the greeting we will have to either find a different work around or we will have to record the greeting, break voice mail to email re-import the greeting and then reconfigure voice mail to email.

As soon as i have more information about a possible work around or resolution to this i will update this post.