Prior to the update, we can see the device running Software version 1.2 (17584)

This can also be seen from the serial or Powershell interfaces by using the Get-HcsSystem cmdlet:

Ensure that both controllers have routable IPs

As suggested by the update instructions, we ensure that both controllers 0 and 1 have routable IPs prior to start. To do so, I ping some external Internet IP address such as bing.com from each of the controllers’ fixed IPs:

For this demo, I will create a new Azure Active Directory (AAD) called Vertitech3AAD and a new on-premise Active Directory called Vertitech3OP.local (NetBIOS name Vertitech3OP) in a new 2012 R2 AD forest.

Configure Password Reset Policy:

Don’t forget to click the Save icon on the bottom center to save and apply your new settings.

Accept the remaining default settings or customize them as needed under the ‘user password reset policy’ section.

I changed the default setting ‘Require Users to Register When Signing in’ from Yes to No. This feature will require users to enter Mobile Phone OR Alternate Email Address as configured in this section. You may want to warn users before hand to expect that requirement, or/and tackle any internal organization/privacy issues related to users’ alternate emails and mobile phone numbers.

One last note here; Password Reset Policy is a directory-wide setting. It will apply to all users. As of 7 March 2016, it cannot be configured to apply to a certain user/group/OU.

SQL mirroring is a popular DR option for SQL databases. It provides a warm standby server where a database can be recovered quickly. Although SQL mirroring is being deprecated by Microsoft in SQL 2016 in lieu of Availability Groups, they share several elements of the underlying technologies.

SQL mirroring popularity is often attributed to

It does not require shared storage like clustering

It does not require a common file share like log-shipping

It can be configured for automatic failover (synchronous mode only) with the configuration of a SQL Witness (3rd server). This option requires that the application/client be mirror-aware (include ‘failover partner=xxxx’ in connection string)

It can be configured in safety/synchronous mode (default), where a transaction is written to both servers before a commit is returned to the client. This requires low latency between the 2 servers.

It can be configured in performance/asynchronous mode, where the primary server sends commit back to client as soon as the transaction is written to the send queue. This may lose data if the primary fails before the transaction makes it to the secondary server redo queue.

It can be configured across distant geographical locations (recommend asynchronous mode and certificate based authentication in this scenario)

It can be configured between 2 servers that belong to different AD domains using certificate authentication.

SELECT * FROM sys.sysusers where name = ‘Vertitech1SQL2_user’SELECT * FROM sys.server_principals where name = ‘Vertitech1SQL2_login’SELECT * FROM sys.certificates SELECT name,port FROM sys.tcp_endpoints

SELECT * FROM sys.sysusers where name = ‘Vertitech1SQL1_user’SELECT * FROM sys.server_principals where name = ‘Vertitech1SQL1_login’SELECT * FROM sys.certificates SELECT name,port FROM sys.tcp_endpoints

To issue Powershell commands from a local (on-premises) workstation, and have them execute on remote Azure virtual machines, requires certificate based authentication in most cases since local machine and Azure VM often don’t belong to the same Active Directory domain. In Azure Microsoft has a large list of VM templates that can be used in the Gallery to provision VMs. These VMs come with few pre-configured features to facilitate secure powershell remoting into the VMs:

WinRM is enabled and configured to listen on HTTPS port 5986

A certificate is already created to enable authentication from remote on-premises computers.