Category: Windows Server

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.

 

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)

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

Differences Between Active Directory and Azure Active Directory

Lately, a lot of people keep asking, “What’s the difference between Active Directory, and Azure Active Directory?” Well, in short, a lot! Here is my take on it, and my typical response to customers.


One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things. One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things.

When you’re focusing on traditional On-Premises AD, you have the ability:

  • Create Organizational Units (OUs),
  • Create Group Policy Objects (GPOs),
  • Authenticate with Kerberos,
  • Working with a single domain (machine joins),
  • Query and interact with Lightweight Directory Access Protocol (LDAP),
  • Domain trusts between multiple domains,
  • And so on…

With Azure AD (AAD), functions mentioned above do not exist. AAD is simply an identify solution, and essentially a federation hub for online services, ie. Office 365, Facebook, and other various 3rd party applications/websites, etc.

  • Users and groups can be created but in a flat structure, things like OUs and GPOs do not exist in AAD.
  • Since there is no domain trust with AAD, federated services are used to create a relationship. This can be achieved with ADFS, which allows On-Prem AD to communicate and authenticate with SSO (Single Sign On).
  • Also, you cannot query against AAD with LDAP, however you can use REST API’s that work HTTP and HTTPS.

Here is a great article, along with many others on the web, that help explain. https://blogs.technet.microsoft.com/chrisavis/2013/04/24/active-directory-differences-between-on-premise-and-in-the-cloud/

 

Monitoring Domain Controllers in SCOM 2016 – Event ID 1102

So  you deploy a SCOM 2016 agent to a Windows 2016 Domain Controller, only problem is, after the agent push, discovery doesn’t work. Well, the agent isn’t corrupted… Ports are open… SCOM agent is being deployed using the System Local account…  etc. etc. So, now what?

Taking a look at the Windows 2016 domain controller and its event log, the domain controller OpsMgr log is getting bombarded with Event IDs 1102….

After some investigation, seems to be this has been an issue in SCOM 2012 (and 2012R2) as well. Well, here’s the fix…

Taking a look at the HSLockdown, the Local System account is being denied access..  Browse to the following folder “%windir%\Program Files\Microsoft Monitoring Agent\Agent “and run the following command (elevated access…), “HSLockdown.exe /L

Now that we can see the Local System account is being denied access, let’s give it access… Running the following command, “HSLockdown /A “NT AUTHORITY\SYSTEM“. Restart the SCOM Agent (net stop HealthService.exe & net start HealthService.exe) and you should be good to go now!

Cheers!

Transfer Active Directory FSMO Roles via PowerShell

Sometimes a domain controller (DC) just needs to be decommissioned for whatever reason, let’s say an upgrade, or corrupted VM and the roles are now seized.. nevertheless, moving the FSMO (Flexible single master operation) roles can be done via the UI, however if you want to speed things up and do it with PowerShell, here is how to that.

In my scenario, I am decommissioning my Hyper-V server which at the time was acting as the primary DC. Now that it is being decomm’ed I need to transfer the FSMO roles to another DC. The destination DC is “DC01” in this case.

Move-ADDirectoryServerOperationMasterRole -Identity "DESTINATION DC" -OperationMasterRole 0,1,2,3,4

You have the option here to specify a numerical value or specifying the role itself. See below for the number assoicated to each roles. You could input each role, or as I did, just input the number(s).

PDCEmulator or 0
RIDMaster or 1
InfrastructureMaster or 2
SchemaMaster or 3
DomainNamingMaster or 4

To verify the FSMO roles have been transferred, run the netdom query fsmo command.

netdom query fsmo