Archive for February, 2016

StorSimple 8k update to version 2.0 (17673)


StorSimple update 2.0 brings in a number of new exciting features such as Locally Pinned Volumes, OVA (On-premise Virtual Array), and enhanced SVA (StorSimple Virtual Array) model 8020 with 64TB capacity as opposed to 30 TB capacity of the prior model 1100 (now renamed 8010).

Update 2.0 is another intrusive update that requires down time. It includes LSI firmware update (KB 3121900), and SSD disk firmware update (KB 3121899).

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

StorSimple20-02

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

StorSimple20-03

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:

From Controller 0 (the prompt must say ‘Controller0>’):

Test-HcsConnection -Source 10.1.2.86 -Destination bing.com

A positive response looks like:

StorSimple20-04

From Controller 1 (the prompt must say ‘Controller1>’):

Test-HcsConnection -Source 10.1.2.87 -Destination bing.com

StorSimple20-05

Phase I – Software update – start the update from the Azure Management Interface

In the classic portal, under the device Maintenance page, click Install Updates at the bottom:

StorSimple20-06

check the box and the check mark:

StorSimple20-07

Pre-upgrade checks are started:

StorSimple20-08

And a Software Update Job is created:

StorSimple20-09

successfully:

StorSimple20-10

Unlike prior updates, the 2.0 update starts on the passive controller:

StorSimple20-11

Under the StorSimple Manager/Jobs page, we can see an update job in progress:

StorSimple20-13

The controller being updated will reboot several times. During the update we’ll see unusual controller health and state information in the portal:

StorSimple20-12

This is normal while the update is in progress.

A few hours later, we can see that the passive controller has been patched to version 2.0

StorSimple20-16

and that a controller failover has occurred, where controller 1 is now active, and controller 0 (now passive) is being patched:

StorSimple20-14

About 4.5 hours the first phase of the update is finished:

StorSimple20-17

We can see the device in normal state and health under the Maintenance page:

StorSimple20-18

Phase II – Maintenance Mode LSI firmware update

Unfortunately this is an intrusive update that requires down time, similar to phase 2 of StorSimple version 1.2 update posted here.

To summarize the steps of maintenance mode updates:

  • Schedule a down-time window
  • Offline all StorSimple iSCSI volumes on the file servers
  • Run a manual cloud snapshot of all volumes
  • On the Device serial (not Powershell) interface, put the device in Maintenance mode:
    Enter-HcsMaintenanceMode
    Both controllers will reboot
  • Patch controller 0:
    Get-HcsUpdateAvailability
    Start-HcsUpdate
    Check update progress:
    Get-HcsUpdateStatus 
  • After controller o is patched repeat last step on controller 1 to patch it
  • Finally exit Maintenance mode:
    Exit-HcsMaintenanceMode
    Both controllers will reboot

The device is now back in normal operating condition, and we can online the volumes back on the file servers.


Setting up Azure AD Connect, 2-way directory synchronization, password write-back, online-password reset


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.

Create a new Azure Active Directory:

As of 24 February 2016, creating a directory is available only in the classic portal (https://manage.windowsazure.com). If you try to do it in the new portal (https://portal.azure.com):

AzureAD01

You’ll simply be redirected to the classic portal:
AzureAD02

I created Vertitech3AAD Azure Active directory in Azure, and created an on-premise AD domain called Vertitech3OP.local in new 2012 R2 forest:

AzureAD03

I can see the new AAD (Azure Active Directory) domain:

AzureAD04

Create new AAD Global Admin user:

We create a new AAD user for AD Connect because we need a Global Admin that has rights to a single AAD. In the new AAD I create a new user with Global Admin permissions:

AzureAD05

The new AAD user is created:

AzureAD06

Change the temporary user password:

Next, I must change the new user password. I browse to https://manage.windowsazure.com, log off and login again using the new user credentials and temp password:

AzureAD07

I’m then prompted to change my password:

AzureAD08

Download and install AD Connect on an on-premise machine:

AD Connect can be downloaded from the Azure AD page or this link.

AzureAD09

Install AD Connect

AzureAD10

AzureAD11

Using Express Settings:

AzureAD12

Enter the AAD Global Admin user name and password:

AzureAD13

And local (on-premise) AD credentials – this account needs to be member of the Enterprise Admins group:

AzureAD15

The message/recommendation about custom domain verification can be safely ignored.

AzureAD16

AD Connect uses SQL Express – but can be configured to use other on-premise full deployment of SQL:

AzureAD17

And we’re all done:

AzureAD18

I recorded the machine services in an XML file before installing AD Connect using the Powershell command:

Get-Service | Export-Clixml .\Services1.xml

After installing AD Connect, I ran this small script to identify new services added:

$Services1 = Import-Clixml .\Services1.xml
$NewServices = @()
(Import-Clixml .\Services2.xml) | % {
     if ($_.Name -notin $Services1.Name) {
         $NewServices += $_
     }
}
$NewServices | sort name | select name, displayname,status | FT -a

We can see 5 new services. Some are running under LocalSystem.

AzureAD20

In Computer Management under Local Users and Groups, we can see a number of new local groups that have been created during AD Connect installation:

AAD06

Only ADSyncAdmins local group has users. It has the local user account (service account for ADSync service) and the domain account that the AD Connect installation ran under,

And in Azure we can see a new Synchronization service account:

AzureAD22

Also, note that Directory integration is now Activated:

AzureAD34

To view synchronization activity, run Synchronization Service Manager (c:\program files\Microsoft Azure AD Sync\UIShell\miisclient.exe)

AAD07

User objects in the on-premise AD need to have inheritance enabled for AD Connect to work and synchronize these objects to Azure AD.

Enable Password Write-back:

We can also see Azure AD Connect icon on the desktop (shortcut to “C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe”)

AzureAD23

Which shows the following options:

AzureAD24

First option is to View Current Configuration:

AzureAD25

Note the default settings above. To change synchronization settings, click Customize Synchronization Options:

AzureAD26

Next we enter our Azure AD Global Admin user credentials:

AzureAD27

And our local (on-premise) AD admin credentials:

AzureAD28

We can select to synchronize all domains and OUs or specific domains and OUs:

AzureAD29

As well as optional features:

AzureAD30

I check the box to enable Password Write-back, and click Install to reconfigure the synchronization process:

AzureAD31

AzureAD32


To test synchronization, I create a local AD user:

AzureAD33

By default AD Connect synchronizes every 30 minutes. To force a manual synchronization I use this Powershell cmdlet on the AD Connect machine:

Start-ADSyncSyncCycle -PolicyType Delta

Now I can see the user in Azure:

AzureAD35

Configure Password Reset Policy:

In the Azure classic portal at https://manage.windowsazure.com, browse to your directory/configure page:

Pwdreset03

Click the Yes button for ‘Users Enabled for Password Reset’.

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.

Finally, users can change their passwords online using the standard Azure password reset pages/links such as https://account.activedirectory.windowsazure.com/ChangePassword.aspx?BrandContextID=O365&ruO365=

Pwdreset01

which can be reached from the settings/password link under https://portal.office.com/account/ for example:

Pwdreset02

 


Setting up certificate based communication between SQL server endpoints for SQL mirroring


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.

This Powershell script automates the last scenario of setting up certificate based communication for a pair SQL 2014 servers in Azure. The script can be slightly modified to work on on-premises SQL servers as well. This script has been tested on SQL 2014 SP1 but should work on SQL 2008 R2 and above.

Region ‘Initialize’ output may look like:

SQL-Mirroring-02

Region ‘configure outbound connections’ output may look like:

SQL-Mirroring-03

Region ‘configure inbound connections’ output may look like:

SQL-Mirroring-04

Finally, region ‘Final Cleanup’ deletes the certificate files and closes open sessions to the 2 SQL servers:

SQL-Mirroring-05

To undo this setup, you can run this TSQL script on the Principal server:

DROP CERTIFICATE Vertitech1SQL2_cert
DROP user Vertitech1SQL2_user
DROP login Vertitech1SQL2_login
DROP endpoint Endpoint_mirroring
DROP CERTIFICATE Vertitech1SQL1_cert

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

and this TSQL script on the Secondary server:

DROP CERTIFICATE Vertitech1SQL1_cert
DROP user Vertitech1SQL1_user
DROP login Vertitech1SQL1_login
DROP endpoint Endpoint_mirroring
DROP CERTIFICATE Vertitech1SQL2_cert

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


Managing Azure VMs using Powershell from your local desktop


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.

This PS script takes advantage of these settings and establishes PS session with Azure VM. Once the session is established, you can issue remote PS commands as shown in the examples.

Azure-RemotePS1

This script is also available as a function. The function facilitate re-using the code to connect to Azure VMs from other scripts.

Here’s an example of using this function in a larger script:

Azure-RemotePS2

This script which sets up certificate based SQL mirroring on 2 SQL servers in Azure, (explained in this post) provides an example of using this function.