customer will be upgrading to 7 on brand new servers. HQ location will have Unity with FO. remote location will have a Unity cold standby (in the event that HQ gets wiped out, they would like to turn on the Unity at remote site and have it take over). how would you go about installing this especially from license stand point?
Did you figure this out? I have pretty much the exact same scenario - Unity with Failover at HQ then they want a Cold Standby Unity Server at a DR site. My concerns are the same as yours - Licensing, Procedure, and the big question in my mind is it is Unified Messaging so the two Servers will both have to be joined to the domain and wondering if they have same or different SID's so I am concerned on how that comes into play.
For licensing, I believe there are 2 approaches (Unity Connection has a similar offering as well). You can license the server in advance based on it's own MAC or you can rehost your existing license when you need to activate the cold standby. From a logistical perspective, I'd think option 1 would be preferred. For Unity, the procedures aren't as clear as Unity Connection so your Cisco AM would probably be able to point you to the correct info source on how this is SKU'd, priced, and how the license gets generated, etc.
They are separate servers with different names and they must be joined to the same domain and communicate with the same message store server. So, they are unique and do not have the same SID. This would be unique as expected. Here are the details about cold-standby for Unity.
Well in our scenario the standby redundancy is not an option because we already have automatic failover configured with a primary and secondary Unity server at HQ.
Regarding licensing, I think re-hosting is the best option because I don't think the customer is willing to purchase a duplicate system, the cost would be too high. Also, I am not aware of a cold standby sku for Unity.
So my next big concern is the actual testing of DiRT to the DR Site. From what I understand when you run the Restore it checks and removes existing Subscriber properties in AD because it assumes it is an emergency, thinking the other Unity Server is gone, and takes over all roles. This allows the new Unity Server to merge existing AD accounts with the Subscribers that are being imported from DiRT. That is good and all from a disaster standpoint but from a testing standpoint poses an issue on how to revert back to production.
So my thinking is I have several options.
1. Replicate everything in a LAB, including Exchange, AD, CM, and Unity. Re-Host License. Test DiRT in the lab and hope it works in production if there is a real disaster.
2. Setup my DR with a VM only, not unified messaging, running a local Message Store and it's own domain allowing the testing of DiRT. Re-Host License. Have the users do without the unified portion of the voicemail if there is a real disaster.
3. Assuming the WAN meets the requirements talk the customer into moving the existing Failover Unity Server to the DR and call it a day.
4. Ghost or other cloning software to replicate to the DR server. Re-Host License and Change IP addresses. Use Ghost / Clone once a week as the backup method. Or Ghost / Clone once and then use COBRAS to import /sync the most recent user data once a week or just keep a COBRAS export handy for an emergency.
5. I have seen some suggest the rotating Hard Drives methods, change IP address, etc... but given the distance and lack of support at the DR site this is not a great option in this particular instance.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.