Month: February 2018

System Center – Operations Manager 1801 is now available!

· Leave a comment ·

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

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

· 5 Comments ·

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)