Making a Self-Signed Certificate

A lot of services on Azure and on-premis require us to create or buy certificates. Now there are a couple of ways to create certificates. I used to do it using makecert

makecert -sky exchange -r -n "CN=<Domain Name>" -pe -a sha1 -len 2048 -ss My -sv <Domain Name>.pvk <Domain Name>.cer 
 
pvk2pfx -pvk <Domain Name>.pvk -pi <Password> -spc <Domain Name>.cer -pfx <Domain Name>.pfx

Recently, I started making my certificates using PowerShell

Has Something Gone Wrong?

Generally, we choose to leverage Read-Access Geo-Redundant Azure Storage Accounts (RA-GRS) because we can use it as part of our disaster recovery (DR) plan. And sometimes, we forget that our devil is in the details. Disaster recovery (DR) plans are rarely tested and can cause headaches when they are. So let’s relieve some of those headaches.

Headache…

“Geo Replication Lag” for GRS and RA-GRS Accounts is the time it takes for data stored in the Primary Region of the storage account to replicate to the Secondary Region of the storage account. Because GRS and RA-GRS Accounts are replicated asynchronously to the Secondary Region, data written to the Primary Region of the storage account will not be immediately available in the Secondary Region. Customers can query the Geo Replication Lag for a storage account, but Microsoft does not provide any guarantees as to the length of any Geo Replication Lag under this SLA.

The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the first items that come up in DR discussions. When we use RA-GRS we control the RTO because we decide when to read from the secondary location. The RPO is a bit different because that can vary due to physics and load. The best way get current Recovery Point (RP) is to get the last sync time for the RA-GRS in question. This post is all about getting the right information, when we need it, because we need facts to make the right decisions.