Following on from my last post on vSphere 7.0 certificate Management, I wanted to continue with another certificate related post. This one being Site Recovery Manager (SRM) 8.3. Like vSphere 7.0, this version seems simpler than previous versions I have used.
With SRM, it’s the Appliance Certificate replacement that I am going to take you through in this blog post.
Firstly log into the SRM appliance management console via https://<srm-fqdn>:5480 and select the ‘Certificates’ option on the left, followed by ‘Generate CSR’ in the top right.
Fill in the information for your certificate, then click ‘Generate and Download’. You then need to process the CSR with your certificate authority, whether thats an internal, public or lab CA.
Once you have your certificate, select the ‘Certificates’ option on the left again, this time followed by ‘Change’ in the top right.
Select the last option in the Select certificate type section; ‘CA-signed certificate generated from CSR’. Then, browse both your newly generated certificate and either you root CA certificate, or the CA chain. Click ‘Change’ once done.
This should complete the replacement of the SRM appliance certificate!
If like me you get an error complaining that the IP or Common name / SAN is missing, make sure the local host field is set to the FQDN when connecting SRM to vCenter.
vCenter 7.0 brings many new features, one of which is a much smoother certificate management experience. There are now 4 main ‘modes’ for certificate management.
These are; Fully Managed Mode, Hybrid Mode, Subordinate CA Mode and finally Full Custom Mode. There is a great article here from Bob Plankers explaining the difference between each.
As mentioned in Bob’s blog, Hybrid Mode is the recommend option, and I will show you that process here in this blog.
Firstly, in your vSphere Client, browse to Administration > Certificates. Then click Actions and select ‘Generate Certificate Signing Request (CSR)’.
Complete the required fields with your information, making sure you have at least added the common name as a Subject Alternative Name to avoid issues with modern browsers. Click Next.
Finally, copy or download your CSR to generate the certificate on the CA of your choosing. Click Finish when ready.
Once you have your certificate, return to Administration > Certificates and this time select ‘Import and Replace Certificate’.
You then need to select the second option. This may seem slightly deceiving but it effectively is the option you need when you have generated the CSR from vCenter like this.
Now browse and select both your freshly produced certificate, and the root certificate or certificate chain if you have issuing CA’s.
Hit replace, then wait for the Web Client to restart with the new certificate.
Now one final step is needed to complete Hybrid Mode. You need to download the VMCA Root certificate from https://<vCenterFQDN by clicking the ‘Download trusted root CA certificates’ option and distributing it to your vSphere admins.
Once distributed and installed on your vSphere admins client devices, they should not get certificate errors when either browsing to vCenter or the hosts it manages.
You could however, get this error due to the default certificate having a 5 year validity period and not being within the new ‘standard’ of 398 days.
NET::ERR_CERT_VALIDITY_TOO_LONG
If you receive this, you will want to adjust the vpxd.certmgmt.certs.daysValid value in the vCenter Advanced Settings. It defaults to 1825, making it 365 (one year) will stop this.
You can then renew the certificate on each host by clicking ‘Renew’ in the Configure > Certificates menu –
Before (5 years) –
After (1 Year)-
If you want to do this renewal via PowerCLI (because…well why wouldn’t you!?) there is a nice function here by Ankush Sethi which does a great job.
I recently assisted a friend who had an issue with DFS Namespaces following an Active Directory Upgrade from 2008R2 to 2012R2. They were faced with not being able to access the NameSpace following the demotion of the last 2008R2 controller and promotion of the final 2012R2 controller.
Upon opening the DFS NameSpace management console, the following error was displayed when selecting the required NameSpace – “The namespace cannot be queried. Element not found.”
After looking in the FRS (File Replication Service) and DFSR (Distributed File System Replication) event logs, I came to realise that the forest was using FRS for replication! This isn’t supported after 2008R2. Ideally, you would have completed the migration from FRS to DFSR before upgrading the domain controllers.
Note: Always make sure you have a backup, snapshot or other reliable rollback method in place before doing anything in your live environment. This worked for me, it doesn’t guarantee it will work for you!
With FRS being the likely cause, I needed to confirm this. I ran the following command to confirm the status –
Dfsrmig /getglobalstate
It returned the following result confirming that FRS was still in fact being used.
Current DFSR global state: 'Start'
Succeeded.
Before being able to look at the DFS NameSpace issue, this needed addressing. Luckily you can still remediate this after upgrading the domain controllers. I would still advise confirming all the prerequisites are in place BEFORE upgrading!
Now onto the migration from FRS to DFSR.
Firstly, run the following command to move the state to the second of the four states. The four states being; Start, Prepared, Redirected and Eliminated.
Dfsrmig /setglobalstate 1
You will then want to run a directory sync to speed things up, especially if you have a large replication interval!
Run the following RepAdmin command to get things moving.
Repadmin /syncall /AdeP
You can then monitor the progress by running –
Dfsrmig /getmigrationstate
You will then see any remaining domain controllers that are yet to have synchronized the new state. Eventually you will see that all domain controllers have migrated to the second state; Prepared.
Now time to move to the Redirected state. Same process as the previous set but this time specifying ‘setglobalstate 2’
Again run the RepAdmin to get replication moving and monitor using the ‘getmigrationstate’ command. As in the previous step, you will eventually see that all domain controllers have migrated to the third state; Redirected.
Last one! Same as before, but this time you want to use ‘setglobalstate 3 –
Once complete you will get confirmation that you have reached the final state; Eliminated.
You will now be able to run the ‘net share’ command to see that the SYSVOL share has been moved to ‘C:\Windows\SYSVOL_DFSR\sysvol’ and that the FRS Windows service is stopped and set to disabled.
Output of the ‘net share’ command
File Replication Service (FRS) service
This should now give you a correctly functioning directory again! You will want to now check the Directory Services, File Replication and DFSR Logs in Windows Event Viewer to ensure you have no further errors.
Now onto repairing the NameSpace. I read a few different blogs and guides for this, some included deleting the NameSpace via ADSI Edit others didn’t.
I found I didn’t need to delete anything, bonus.
The get the NameSpace accessible again I found that right clicking the NameSpace and removing it, followed by recreating it using the ‘New NameSpace Wizard’ did the trick.
Upon recreating it, all of the folders reappeared and were accessible again with no additional configuration required. (these screenshots are of my lab, not the live environment as it was not appropriate)
Stephan McTighe 