Azure StorSimple Failing Over a Physical Device to the Virtual Appliance for DR

Azure’s StorSimple device is a Hybrid Cloud Storage solution from Microsoft. I assume you already know what StorSimple is if you are reading this blog post on Disaster Recovery for the unit. If you do not, you can download a PowerPoint I created as an Introduction to people who are not familiar with StorSimple. You can download it here

In the event you StorSimple appliance (unlikely as it’s redundant at every component) fails, it is possible to failover your Volume Containers to a Virtual Appliance edition of the StorSimple software running in Azure. The Virtual Appliance (or VSA) is basically an Azure IaaS VM that is running a subset of the StorSimple code. You must have Cloud Snapshots already in Azure of your Volume Containers that reside on your physical appliance in order for this to work. You will probably have a Backup Policy configured to do Cloud Snapshots of your StorSimple at certain intervals.

As I am doing this failover in a test environment my physical appliance has not actually failed therefore I am going to simulate this by taking my Volume Container offline manually, this is done from the Volume Containers page. If your physical appliance had failed, you could miss this step.

You must also deploy a StorSimple VSA before you start, use the Create Virtual Device option from inside the StorSimple manager. When you run through creating a StorSimple VSA, you must provide it with an Azure vNet and Storage Account to be provisioned into. The Azure vNet is important as you will also need a Windows VM on that same network so that you can make a new iSCSI connection to the VSA once failover is complete.

Highlight the physical appliance and click Failover. Select the Volume Container you want to failover onto the VSA and click Next.

Select a Target Device (this should be your VSA that you provisioned), please note that if your VSA does not appear under this list it’s probably because you have not completed the configuration of the VSA. The VSA requires post deployment configuration for things like the Encryption Keys etc. Click Next.

Review the failover summary page and tick the I accept the ……….and click Next.

This will create a failover job for the Volume Container, you can view the progress under the Jobs menu.

Now highlight and click on the VSA.

Click on Volume Containers and then click onto the Volume, the next stage is to create an ACR (Access Control Record) for the new Azure iSCSI VM. Without this the Azure VM won’t have access to the iSCSI Initiator (VSA).

Click Modify.

I have already created an Azure VM and dropped it into the same network as the VSA. Connect to this VM as we will require the iSCSI IQN in order to create the ACR.

Launch the iSCSI Initiator and click on Configuration. Copy the iSCSI Initiator string.

Return to the Volumes page on the StorSimple Manager, you must take the Volume Offline before you can amend the ACR’s.

On the Additional Settings page, create a new ACR using the VM’s name and the iSCSI IQN.

Use the Bring Online button to bring the Volume back up.

Return to the Azure VM iSCSI Server and on the Quick Connect box, type the StorSimple VSA IP, you can get this from the device summary or from the Azure vNet itself. All going well it should make a connection to the VSA.

Rescan the disks from Disk Manager and you should be able to see the files that were stored on your StorSimple physical appliance.

VMware Horizon View 6.0 vSphere Integration “A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code 46.”

When you try to integrate your VMware View Connection Server to the View Composer Server, you receive the error “    “. The following error “A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code 46.” Is also logged into the View Composer’s Events Logs. As soon as I seen this I began to think it was something to do with certificates, the error from the VMware side was next to no help whatsoever.

It would make sense as I installed View Composer, and then renamed by vCenter Server/Composer Server when I joined it to the Domain. The first stage was to open the Certificates (Local) console and check what VMware View Composer certificate was present.

As View Composer was installed before the name change the randomised Windows hostname was present within the View Composer’s certificate Common Name field within the certificate.

When I was running through the wizard to integrate vCenter and View Composer with the View Connection Server, it also stated that the “Server’s certificate subject name does not match” which all made sense at this point.

The first thing I tried was to reinstall the View Composer component, this worked to a degree. It did generate a new certificate but it did not populate the certificates Common Name properly, it defined the Common Name to “VC”, instead of “VC.tatiwynd.co.uk” which was required to get rid of the error above. The next step was for me to issue a new certificate to the View Composer server, using the proper Common Name. I did this by using my internal AD CS infrastructure (used Web Server template), and manually populated the Common Name with “VC.tatiwynd.co.uk”.

Once this was done and the certificate was present inside the Local Computer’s Certificate store, the next part was to use the VMware SviConfig utility to rebind the View Composer’s certificate. Before you do this, you must stop the View Composer service on the server.

Cd C:\Program Files (x86)\VMware\VMware View Composer SviConfig –Operation=ReplaceCertificate –Delete=False Select option using numbers for your new certificate

Restart the View Composer service on the server. When you try to run the integration wizard again you will notice that the error message has changed, to something not as dramatic.