How to Increase ASR (Azure Site Recovery) Replication and Failback Default Settings

Now that you have deployed ASR (Azure Site Recovery), for Hyper-V and have started to up being replication, you notice the replication process just might take forever, as there are several VMs still queued. That is right, by default, ASR will replicate 4 (four) VMs at a given time. This value can be increased (to a maximum of 32), however, where to change this setting?

In order to increase the number of replication threads from 4 to 32, or whatever in between, you first need to launch the Registry and navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication

From there, you will need to create the key, if the key does not exist (I have never see it by default in any of my deployments…). Create the key, “UploadThreadsPerVM” and set its value to whatever you see fit. Again, the maximum is 32.

Likewise, you can increase the default (4) number of threads used for data transfer during failback. This value represents the maximum number of VMs that will failback from ASR. That path is the same, and the Registry Key is,”DownloadThreadsPerVM“, and again, can be set to a maximum of 32.

After that is completed, your Hyper-V Registry Keys, would look something like this. Please note, this change is fully supported by the ASR/Microsoft team. However, do note, this change can saturate your network due to the increase in uploads to Azure. You can also increase and change the schedule for the bandwidth throttle settings, you can see that previous post here, see Step 10.


For additional information on this, please visit,


Azure Update Management – Part II

A little while ago, I blogged on OMS’ (Operations Management Suite) Update Management Solution. As great as this solution was, there were some limitations at the time, such having the ability to exclude specific patches, co-management with SCCM (Configuration Manager), and few others.

Since that post, there have been some great improvements to Update Management, so let’s go over some of the key updates, and do a quick setup walk-through:

  1. Both Windows (2008R2+) and (most) Linux Operating Systems are supported
  2. Can patch any machine in any cloud, Azure, AWS, Google, etc.
  3. Can patch any machine on-premises
  4. Ability to Exclude patches

One of the biggest improvements I want to highlight is, the ability to EXCLUDE patches, perhaps in time there will also be INCLUDE only patches. 😉

First, we need to get into our Azure VM properties.. Scroll down to the Update Management.

  • If the machine belongs to a Log Analytics workspace, and/or does not have an Automation Account, then link it now, and/or link/create the Automation Account
  • If you do not have an Log Analytics workspace and/or an Automation Account, then you have the ability to create it at run-time now.

In this scenario, I kept it clean as possible, so both the Log Analytics workspace needs to be created, and likewise for the Automation Account, and Update Management needs to be linked to the workspace.

Once enabled, it a few minutes to complete the solution deployment….

After Update Management has been enabled, and it has run its discovery on the VM, insights will be populated, like its compliance state.

Now we know this machine is not compliant, as it missing a security update(s), in addition, missing 3 other updates too. Next, we will schedule a patching deployment for the future. So let’s do that now.

Now we can create a deployment schedule with some base settings, name, time, etc. But one thing to note, we can now EXCLUDE specific patches! This is a great feature, as let’s say, we are patching an application server, and a specific version of .NET will break our application, as the application Dev team has not tested the application against the latest .NET framework.

In this demo, I am going to EXCLUDE patch, KB890830.

Next, we need to create a schedule. This can be an ad-hoc schedule, or a recurring schedule.

Once you hit create, we can now see the Deployment Schedule, under Scheduled Update Deployments.

You can also click on the deployment to see it’s properties, and which patches have been excluded.

After the deployment has initiated, you can take a look at its progress.

If we go into the Update Deployment (yes, I got impatient, and deleted the first one, and re-created it…), and click on the Deployment we created, we can see the details.

As you can see, patch, KB890830 was not applied! Awesome.

If we not go back to the Update Management module, we can now see the VM is compliant.


Azure Virtual Network (VNet) Peering

In this blog post, I will go over,

  • What is Azure VNet (Virtual Network) Peering,
  • When to use VNet Peering,
  • How to implement VNet Peering.

What is Azure Virtual Network (VNet) Peering?

Azure VNet (Virtual Network) Peering enables resources within two separate virtual networks to communicate with one another. Leveraging Microsoft’s backbone infrastructure, the two peered virtual networks will communicate over its own isolated network.

Below we have two Virtual Networks (VNet01 and 02), that have different IP Address spaces. By implementing VNet Peering, the two networks will be able to communicate with one another, as if all resources are in one network. Some notes, VNet Peering is not transitive, ie. If VNet01 and VNet02 are Peered, and VNet02 and VNet03 are Peered. This means, VNet01 and VNet03 cannot communicate with one another. Another note, inbound and outbound traffic in the VNet Peer are $0.01 per GB. Prices are a bit higher for Global VNet Peering. Get the official numbers here,

When to use Azure Virtual Network Peering?

As mentioned above, you want to enable Azure VNet Peering when you have two virtual networks that have resources (VMs) in both networks that need to communicate with one another. For example, let’s say you have exhausted 4,000 VM limit within a VNet…

Some of the benefits of VNet Peering is:

Before you go ahead and implement, there are a few requirements:

Finally, how to implement it!

In this example, both of my virtual networks (VNets) are in the same region, Canada Central.

Select VNet01, and select Peering:


Give the Peering a name, “VNet01Peering” and select the other VNet, VNet02.


Give it a few seconds, and it should now be connected to VNet02:

Next, we now need to apply the same concepts to VNet02. So let’s do that now.



Now if we go to the VMs within each of the Virtual Networks, and try to ping another VM in the other VNet, it should now work! Based on the images below, you can see the Ping failed, that was from a previous ping response prior to VNet Peering being implemented.

VM01 in VNet01 trying to Ping VM02 in VNet02; -> ->

And conversely, the other way around…

VM02 in VNet02 trying to Ping VM01 in VNet01; -> -> : ->


System Center – Operations Manager 1801 is now available!

Yesterday afternoon, Microsoft released Operations Manager (System Center, SCOM) version 1801. This is a major change from previous versions of SCOM/Operations Manager, as it now introduces the same release cycle as Windows Server 2016 and Windows 10, ie. Semi-Annual Channel (SAC).

Like Server 2016, and Windows 10, all new features and updates will be delivered in the Semi-Annual Channel (SAC) manner.

Within the Semi-Annual Channel (SAC) model:

  • Each build, ie. 1801 is supported for a minimum of 18 months from its release date;
  • Consistent updates and features within the 6-months (semi-annual) time frame;

In the Operations Manager 1801 version, some of the new features include:

  • Service Map integration;
  • Linux Kerberos support;
  • Linux Log File monitoring improvements;
  • Improvements to the SDK performance;
  • Telemetry for HTML5 dashboard, plus improvements/performance;
  • 3rd Party Management Pack – Updates and Recommendation;

For more information, have a read at the Microsoft blog post:


Over the next few days, I will spend some time on deploying Operations Manager 1801, so stay tuned for that post! Until next time.

If you want to deploy Operations Manager 1801, go here for the System Center Evaluations download:

Wait, Installing Windows Servers CALs on an Azure VM isn’t your last step….

Recently I was presented with a problem, where the client needed to increase the number of terminal services (RDP sessions) from the default 2, to 5. The server was a virtual machine (VM) that was being hosted on Azure, and it was a Windows Server 2016 VM. So, simple solution, right? Just install the Terminal Services (Remote Desktop Service) roles, purchase and install the 5 CALs, and walk away.

Well, after I installed Terminal Services, and configured the Remote Desktop roles, installed and activated the 5 CALs, User3 was still unable to login without kicking User1 or User2 off the machine.

Turns out, the end-users were given the RDP file from the Azure portal, which was fine, however when that specific file was downloaded and used by the end-users, it contained the administrative switch set to true. With this property enabled, User3 would never be able to login without kicking one of the other users off. So, what to do?


Opening the RDP file, and modifying the administrative switch from 1 to 0, was the trick! Gave the users the updated RDP file, and all good. Users3, 4 and 5 were now able to log on to the server.

If you’re curious, below is an example of the RDP file contents, (Open it within Notepad). When you download the RDP file from the Azure portal, it will contain the following info, public IP of the server, prompt for credentials, administrative…. You will need to change the administrative switch from 1 to 0, and save the file. Of course, you still need to install the Terminal Services, purchase the CALs, and install, etc. etc.


full address:s:512.802.768.266:3389
prompt for credentials:i:1
administrative session:i:1


FYI, Group Policy has nothing to do with this, so that was eventually removed as a part of the solution. (

How to Deploy Office 2016 ProPlus Click-to-Run (C2R) with ODT and SCCM

In this blog post, we will be deploying Office 2016 ProPlus (retail; Click-to-Run (C2R)) with Office 2016 Deployment Tool (ODT) and System Center Configuration Manager.

Office 2016 Deployment Tool (ODT)

To begin, we need to get the Office 2016 Deployment Tool (ODT). That can be downloaded from here, Microsoft Download Center. Create a folder on your SCCM application source folder, I called mine, “Office 2016“. Install the deployment tool on your SCCM server, save the extracted files to the folder you just created. Once the installation is complete, the following two files will be found:

Next, we need to create an XML file within the folder. I copied the original “configuration.xml” and called it, “Office 2016 Config.xml” and updated its contents to below. In my deployment, I am deploying Office 2016 32-bit. However, if you are deploying 64 bit, then just change OfficeClientEdition=”32″ to OfficeClientEdition=”64″.

<Add SourcePath="your path to source files" OfficeClientEdition="32"> >
 <Product ID="O365ProPlusRetail">
 <Language ID="en-us" />

Next, we need to run Command Prompt (run as Administrator), and run, “setup.exe” with the XML file we just created/modified. After this completes (give it a few minutes), you should now have the following four files within your folder.

setup.exe /download "Office 2016 Config.xml"

Next, we need to update the, “configuration.xml” file. This file is used to deploy Office 2016. As previously, we have set the version to 32-bit, again change this to 64, if you are deploying 64-bit Office. In this deployment, I am deploying a per-user licensing model, if you are using a product key per machine, you will need to add, “PIDKEY” value to the configuration file.

<Add OfficeClientEdition="32">
<Product ID="O365ProPlusRetail"
<Language ID="en-us" />
<Display Level="None" AcceptEULA="TRUE" />

Now we are ready to create and deploy our application package!

Create Application Deployment

First, we need to create the application package. We will choose the manual “Manually specify the application information” approach here.

Next, we need to provide some application information. Office 2016 deployment, owner, etc…

Now we need to add and create the deployment type

Next, we will choose “Manually specify the deployment type information“.

Again, give this deployment a name, and some descriptive comment(s).

Now, we need to specify the location of the source/installation file(s), and need to specify the “configuration.xml” file.

Next, we want to add a detection clause. Essentially, this deployment, once deployed, will validate against this code to confirm the installation was successful and both the detection code and product code match.

Note, if the deployment “fails”, yet the Office suite installed, confirm the product code and detection code match.

For the detection method, we will choose, Windows Installer, and the following Product code: {90160000-008C-0000-1000-0000000FF1CE}.

Next we will select, Install, and leave the Logon requirement to either.

We have no requirements and/or dependencies for this, but for completeness, here are those screenshot windows.

Great! Deployment is complete. Now we need to complete the application deployment wizard.

Great, application deployment is now complete. Now we need to deploy the package itself… Let’s do that.

Deploy Package Deployment to Collection(s)

Right click and select your collection, in this case, my collection is a test group, named “Test1”.

Specify the distribution point

We are going to mark Install and Available for the deployment settings here.

Provide a set time for the deployment to kick off, remember to set it to the correct time of day.. (struggled for a few deployments, after learning I forgot to set to AM…)

We will give the user the option to install, as the update will appear in their Software Center.

Now we if go to our client machine(s). I am testing on both Windows 7 and Windows 10 machines.

Validate Deployment

If we go into the Software Center, check under the “Available Software”, we now see the Office 2016 ready for deployment! Go ahead hit Install Selected, and let the magic happen!

Windows 7

We can validate the deployment, as we see the Office 2016 applications within the start menu.

Likewise for Windows 10:


For complete information on this deployment, please feel free to visit Microsoft’s article.

Configuring RSA Authentication Agent for ADFS 3.0 + Office 365

Security/Multi-Factor (MFA) are some of the big buzz words this year (2017) and when deploying Office 365, MFA (Multi-Factor Authentication) is almost a no-brainer. In the following post, I will demonstrate how to configure RSA Authentication Agent for ADFS 3.0. There has been some configuration done prior to the agent deployment, ie. TCP/UDP ports, RSA Auto-Registration, sdconf.rec export, etc. For the full documentation, please see the footnotes from RSA and Microsoft for ADFS 3.0 for implementation requirements guidelines.

Let’s get started. Please note, the following is for a Windows Server 2012 R2 (ADFS 3.0) and RSA Authentication Agent 1.0.2.

You will need this, “sdconf.rec” file from your RSA Administrator(s).


Next, within the ~\RSA\RSA Authentication Agent\AD FS Adapter\ folder, copy the “ADFSRegistrationSample.ps1” script to the “SampleRegistrationScripts” folder. This is a known bug in RSA Authentication Agent 1.0.2, as the file should be within the folder by default, but it is not.

Execute the PowerShell script as Local Administrator…

Now you should be able to see the RSA configurations within the AD FS management console.

If we go into the to Authentication Policies > Per Relying Party Trust > we can now edit the MFA settings for Office 365.

For this demo, we will enable both, Extranet, and Intranet.

Enable the RSA SecurID Authentication. Now if all was configured correctly, users within the Office 365 portal will be prompted for an RSA token once they supply valid Office 365/AD credentials!