Author: Ravi Yadav

Ravi Yadav is a Senior Technical Consultant @ Infront Consulting Group. Working specifically with Microsoft System Center suite, specializing in Operations Manager, OMS (Operational Management Suite), Management Pack (MP) Dev, Configuration Manager and Virtual Machine Manager. He is based out of Canada, and when he is not at his PC, he enjoys reading, cooking, photography and keeping up with the Toronto Blue Jays.

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: https://docs.microsoft.com/en-us/system-center/scom/what-is-new-1801?view=sc-om-1801

 

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: https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-release

Advertisements

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. (https://support.microsoft.com/en-us/help/2833839/guidelines-for-installing-the-remote-desktop-session-host-role-service)

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

In this blog post, we will be deploying Office 2016 ProPlus (retail) with Office 2016 Deployment Tool 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″.

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

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.

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

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!

 

 

 

System Center Virtual Machine Manager (SCVMM) 2016 – Error 2912 – Unknown error (0x80041008)

Problem: Cannot to deploy a logical switch (vSwitch) to a Windows Server 2016 node.

Environment: 2x10GB Network Cards – IBM Flex Chassis (not that matters…)

Error:

An internal error has occurred trying to contact the ‘hypervserver01.domain.com’ server: : .

WinRM: URL: [http://hypervserver01.domain.com:5985], Verb: [INVOKE], Method: [GetFinalResult], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AsyncTask?ID=1001]

Unknown error (0x80041008)

Recommended Action
Check that WS-Management service is installed and running on server ‘hypervserver01.domain.com’. For more information use the command “winrm helpmsg hresult”. If ‘hypervserver01.domain.com’ is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running. Refer to http://support.microsoft.com/kb/2742275 for more details.

Solution: In my case, I tried the following. Ultimately, it came down to my last case (enabling the physical network card).

  • Disable Windows Firewalls on both SCVMM and the Hyper-V 2016 server
  • Change the default WinRM port to 5985
winrm set winrm/config/Listener?Address=*+Transport=HTTP '@{Port="5985"}'

  • Enable the secondary physical port

Connect Batch of Azure VMs to Log Analytics (OMS) via PowerShell

So, you have a bunch of Virtual Machines (VMs) in Azure, and didn’t used an ARM template, and now need to connect the VMs to Log Analytics (OMS). Earlier this month, I demonstrated on this can be done with the ARM portal, here’s that blog post. Of course, this has to be done individually and can be very tedious if you have 10’s or 100’s of machines to do this to… All I can think of is PowerShell!

Here is a script I tweaked that Microsoft has already provided but for a single VM. I have just tweaked it to automate and traverse through your entire resource group, and add ALL VMs within the RG to Log Analytics.

Here is the link to Microsoft TechNet for that script. Please test it out and let me know. And if it helped you out, please give it a 5 start rating.

Microsoft TechNet PowerShell Gallery

If all went well, your before and after should look similar to this. I had two test VMs in my Resource Group.

Before:

After:

(more…)

What is Azure File Sync (AFS) and how to set it up?

Earlier this month, Microsoft introduced Azure File Sync (AFS). So, what is Azure File Sync (AFS)?

Azure File Sync is a cloud based backup solution for backing up and providing disaster recovery options for a single, or multiple file shares within a server, or multiple servers. Some of the benefits are:

  • Eliminates network and storage complexity and capacity planning, as it is done for you in Azure.
  • Changes to on-premises data are synchronized in real time to Azure, and file/folder backup is completely seamless to the end-user(s).
  • At the current time, AFS offers 120 days of data retention.
    • I suspect this will increase over time, and will allow administrators to have options with higher or lesser days of retention.

Setting up and configuring Azure File Sync is pretty quick. Below is how I setup Azure File Sync to sync a folder/files from my local server to Azure. AFS is pretty cool stuff, and I have been wanting to chat about it for some time (NDA). At any rate, getting AFS setup is pretty easy. Microsoft provides pretty good documentation on how to do this as well, but in my opinion, they have elected to omit some steps. Here is my take:

First you will need to create a new Azure File Sync Storage Sync. Within the Azure marketplace, search, “Azure File Sync“. Note, Azure File Sync is currently only available to a limited set of regions:

  • South East Asia
  • Australia East
  • West Europe
  • West US

Once created, under Sync, and getting started, download the Storage Sync Agent.

Note, Azure File Sync currently only works with Windows Server 2016 and Windows Server 2012 R2 (servers must be installed with a GUI — no core).

Download and install the agent on your local server, and configure it to the Storage Sync Service you just created in Azure.

Whoops, since this a brand new server install, there is no AzureRM PowerShell modules installed. Go ahead and launch PowerShell as an Administrator, and execute the cmdlet, “Install-Module AzureRM -force

Okay, back to the install. Remember to select the Storage Sync Service you just created in Azure

Once the install is complete, go back to Azure, and under Sync, Registered Servers, your local server should now be present.

Great, now we need to create a Storage account. We can either chose an existing storage account, or create a new one – I chose the ladder.

Regardless with route you take with the Storage account, go into the Storage account properties, and scroll down to File Service, and select Files.

Create a File Share, give it some name, and some quota. I gave it 1GB, as this is simply for testing and PoC. The file path is the same file path you want to backup to AFS. This file path should already exist on your local server(s).

Now go back to your Azure File Sync, and under Sync, and Sync Groups, create a new Sync Group. Within the Azure File Share, select the File Share we just created within our Storage account.

Finally, now we can create an server endpoint. Go back to your Sync Groups, and create a new server endpoint. Here you will need to specify the file/folder you will want to share/copy/backup to your Azure File Sync (AFS).

And that is it! Next I will show you how you can actually restore from your Azure File Sync.