Xenit Technical – Unbox your business

SCCM 1806 – News and features

Once more it was time to upgrade our SCCM environment to the newest release that is 1806. As it was not released for everyone yet, I had to run the Fast-Ring script to allow the update to present itself. I found this update very interesting as it comes with some exciting new features, and there are alot. These are the ones that I am most excited about.

  • Ability to PXE boot without WDS
  • CMTrace installed as default on clients
  • Ability to exclude Active Directory containers from discovery
  • High availability on Site Server
  • CMPivot
  • Boundary group for peer downloads
  • Enhanced HTTP site system
  • Improvements to OS deployment
  • Software Updates for third-party

…and much more. You can read about all the new features here on Microsoft docs.

Since there are a lot of news, I have chosen to cover the two that I am most excited about in this new release.

CMPivot

Configuration Manager is a very helpful tool when gathering information, CMPivot now allows you to take it to the next step by real-time querying clients. This allows you to gather a lot of information instantly. This feature uses Azure Analytics Language, .

CMPivot is located under Asset and Compliance > Overview > Device Collection, you can find this new feature in the top ribbon bar.

Location of CMPivot

An example is to find BIOS-information about the Dell computers that are currently online. From this output you easily create a collection (the members of the collection will be added as Direct Members) or export to both CSV and Clipboard.

 

PXE Without WDS

It is exciting to have a new way of deploying over PXE. Since Windows Deployment Services has been available for a long time, it feel suitable to have an updated way of deploying clients. By replacing WDS, the distribution point will create the service ConfigMgr PXE Responder. If you have plans of using Multi-Cast, you are for now stuck with WDS.

This setting can be found under Administration > Overview > Distribution Point, right click on the distribution point you would like to modify with the setting shown below.

After applying this setting, Windows Deployment Services will automatically be disabled. Be advised that if you are monitoring this service, it will be report as stopped. SCCM PXE Without WDS

If you have questions, thoughts or anything you would like discuss? Send an email to Johan.Nilsson@xenit.se and I will be more than glad to talk about these topics.



Datetime and RFC3339 compliance in powershell – a deepdive

A collegue of mine asked if there is a way to output a RFC compliant datetime (https://www.ietf.org/rfc/rfc3339.txt) in powershell without manually formatting in T and Z in the middle and end to comply with ISO standard and imply UTC +-00:00

 

Before i start with the how, I’d like to address the why.

If you’ve ever done some coding you’re sure to have encountered issues with datettime and possibly errors and incidents due to the timeformat of a datetime string.
For example, if I live in the US then time is commonly written in month-day-year format, which during the first 12 days of each month is indistinguishable from the european day-month-year format.
This is also encountered in code, for example in powershell my locale is Swedish and the ”Get-Date” cmdlet returns ”den 1 augusti 2018 16:35:24” which is easy and readable for a human.
However if i convert it to a string it becomes in US format even though my culture settings in powershell is set to swedish.
In my opinion this behavior is wrong as I expect to be given a ISO standard universal format, or at least a culture appropriate format. Instead I am given a US format.

With that said, developing automation and tools for global customers a standard format is much needed when we write to logs.

The How

After a short time on google it seems no one had done this properly in powershell. I also found out that XML is RFC compliant.

How did i do it?

Returns:

Great! Now let’s put it into some real code.

Example 1: Writing current date into a logfile

The output becomes a RFC compliant string and gets stored in the $now variable to be used into a out-file log operation.

Example 2: Writing a job deadline datettime

Here we create a datettime object, add 20 hours and then convert it to a RFC compliant datettime string and store it into the $RFCDeadline variable.

Hope this helps someone!



Azure AD Connect and .NET Framework 4.7.2

Introduction

Last week a discussion erupted on Microsoft forums regarding Azure AD Connect due to it’s Monitoring Agent using all free resources of CPU on the servers. These issues were caused by a .NET Framework update and a lot of administrators spent time uninstalling and blocking these patches to resolve the CPU usage issues on their servers. On Saturday Microsoft released an update (KB4340558) which contains a collection of several patches where one of the earlier mentioned .NET Framework updates were included. For more information, see this link.

Microsoft has recently published an article regarding this issue. In addition, Microsoft also published a new version of the health agent where they state that the issue is resolved, it can be downloaded from here. The new health agent version is set to be included in the next version of Azure AD Connect, which will be published for Automatic Upgrade (Auto Upgrade). The following patches have been identified with issues causing Azure AD Connect’s monitoring agent using huge amounts of CPU:

Auto Upgrade

In version 1.1.105.0 of Azure AD Connect, Microsoft introduced Auto Upgrade. Although, not all updates are published for Automatic Upgrade. Whether a version is eligible for automatic download and installation will be announced on Microsofts version-history website for Azure AD Connect.

You can verify whether your Azure AD Connect installation have Auto Upgrade enabled by either using Powershell or viewing your configuration in It’s GUI.


Graphical User Interface of Azure AD Connect
PowerShell-command for determining whether Auto Upgrade is enabled or not.

This command will return either Enabled, Disabled or Suspended, where as the Suspended state only can be set by the system itself. Newer installations of Azure AD Connect enables Auto Upgrade by default, in case your installation applies to Microsoft’s recommendations. For more information, see this link.

Enabling Auto Upgrade

In case you have an installation of Azure AD Connect older than 1.1.105.0 (February 2016), Auto Upgrade will be disabled, if you’ve not enabled it manually. Enabling this function can be done with below PowerShell-command if so wanted.

If you have any questions, feel free to email me at robert.skyllberg@xenit.se



Enable Exchange Mailbox Auditing for all users

Enabling Mailbox Auditing as an Exchange Administrator has for a long time been something you have need to do manually.

Yesterday, Microsoft announced that they will be enabling mailbox auditing by default for all user mailboxes using Office 365 and Exchange Online. This is a welcome change, so you don’t need to manually enable mailbox auditing on new users or use a script that enables that for all users in Office 365 and Exchange Online.

For on-premises Exchange environment, there is no such feature (hopefully it will come with a future Cumulative Update) so you still need to change it manually. Either you add this as a process when creating a new mailbox, or you can use a PowerShell script as an Schedule Task on your Exchange Server that will automatically enable auditing.

Here’s an example on how such script can look like, and you can find it as a download here.



Black screen at session logon with VDA newer than 7.15 CU1

The black screen of death

Introduction

The logon process for users accessing a XenApp/Virtual App-environments is not completely simple to explain or understand in its entirety. There are several processes and services that need to work together, to let a user log on and begin to work in a virtual session. An issue that is not especially uncommon with regards to the logon process is what I would like to call the Black screen of death, BSOD. This should not be confused by the other BSOD! 🙂 When an environment has black screen issues I know that the troubleshooting and eventually finding a solution could most likely be long and challenging.

There have been several discussions regarding black screens at logon lately, especially when looking at Virtual Apps (i.e. XenApp) and published desktops. There are some obvious, and quite straight forward reasons why users get a black screen at logon. I’m not going to get into those in this blog post, apart from mentioning two really good articles from Citrix on the subject; XenApp/XenDesktop : Black Screen Is Displayed While Launching A Published Applications From Windows Server 2016 VDA [1] and XA/XD – Black or Blue Screen Connecting to Published Desktop [2].

I would also like to shed some light on a second ”Black Screen-issue” also currently discussed, the Windows-service AppReadiness and black screen at logon. Funnily enough, it seems like that issue is also introduced with VDAs newer than 7.15 CU1. If there’s an interest in diving into that issue too, I’m happy to do so in another blog post. My explanation of that issue can be found on the Citrix Discussion forum [3].

Last but not least, the latest of all ”Black Screen-issues” I have encountered, and the topic of today’s blog post.

Scenario

Users log on to a published desktop where the VDA is newer than 7.15 CU1, in my case i tried them all, 7.16, 7.17, and the newly released version 7.18. The session went black at logon and explorer.exe did not start. Even after waiting for more than 30 minutes. It did not matter if it was new profile or existing, in this case Citrix User Profile Mgmt, nor did it matter if the VDA was newly installed or updated from 7.15 CU1. Sending CTRL+ALT+DEL did not do a thing.

Everything worked fine on VDA 7.15 CU1 and previous versions, the only change I did to the MCS image when this occured was updating the VDA.

BSOD when initiating a new user session

Troubleshooting

I did some initial trial and error without any luck, so I decided to use my favorite troubleshooting tool, Process Monitor (aka Procmon). Within a couple of minutes I noticed that there was a process stuck in some kind of never-ending loop when a user tried to log on to the VDA. The process stuck was the ”Citrix Profile management message utility”upmEvent.exe [4].

What I also could see was that the process upmEvent.exe was the last process during the logon before the login process got stuck, and the user got the BSOD. I could not at the time identify exactly why, other than I knew which process broke the attempted login. It didn’t matter if it was a new or existing profile.

After having identified the culprit process I forcefully terminated it, and boom, the login process progressed as we are used to. Explorer.exe and all the other processes eventually started like nothing was wrong. From a user perspective, everything began to work and the desktop was shown as soon as the process upmEvent.exe was terminated.

From experience I knew that this was not the first time that specific process have have had different kind of issues. If you do a quick Google search on “upmEvent.exe” you will see that there have been some interesting issues with it over the past. The last change I know of, were when customers needed help because Citrix made a change in how it should be configured to upload data to Citrix Director. In short that change was needed because we hade to change from using UpmUserMsg.exe to upmEvent.exe. I also knew that the startup of the process had been changed previously, from the Run-key to the Userinit-key. From this I had reason to believe that this scenario might not be very different from last time [5] [6].

To summarize

I knew that upmEvent.exe by default has moved from the legacy Run-key to Userinit starting the process in user context. I also knew that the way the process needs to be configured has historically changed depending on what VDA-version is used. What I finally knew was that the configuration of the process is usually controlled in one way or another, for example with a scheduled task, GPP, GPO, registry, or something completely else.

I did a quick check to verify that the Key changed between my two VDA-versions.

Citrix VDA 7.15 CU1 is not using the Userinit registry key

Citrix VDA 7.18 is using the Userinit registry key

Indeed, there’s a difference! Closer to the solution, great!

In this specific environment I found out that the user-context startup of the upmEvent.exe-process was made with a GPO. When looking at the configuration I could see that it was configured in the old way of using upmEvent.exe. Not the new way of doing it!

The GPO configuration

Solution

When the VDA was updated to a newer version than 7.15 CU1 the GPO was reconfigured at the same time. In this case we removed the logon script and let the VDA configure the Userinit registry value. When the MCS machine was rolled out everything worked as it should, even though the VDA was updated!

I didn’t do more digging than needed, as I could see that everything started to work after the reconfiguration. It seems like newer versions of the VDA, and the move to Userinit, collide with the GPO configuration. Because of the collide the users gets a black screen at logon. A deadlock occurs when the script and Userinit is configured to run the process at the same time.

Hope this helps someone out there!

References

[1] https://support.citrix.com/article/CTX135782

[2] https://support.citrix.com/article/CTX235681

[3] https://discussions.citrix.com/topic/394538-continued-problems-with-black-screen-at-session-start-with-windows-10/?do=findComment&comment=2006811

[4] C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe

[5] https://www.jgspiers.com/reduce-citrix-director-interactive-session-time/

[6] https://tech.xenit.se/oregelbunden-loggning-av-inloggningar-citrix-director/



Exchange Server and .NET Framework 4.7.2

Yesterday Microsoft released a new version of .NET Framework, 4.7.2 and it’s showing up as an important update in Windows Update.

For Exchange Servers it’s important that you don’t install this update as this version, at this time, is not part of the support matrix for Exchange Servers:

The full list of supported .NET Framework versions are available at Exchange Server Supportability Matrix – Microsoft .NET Framework

To block the installation of .NET Framework 4.7.2 from Windows Update, you can run the following command:

This will add the following registry key:

To unblock the installation, once it’s supported you can run the following command:


This will remove the registry key from the computer and the update will be available once again from Windows Update.



Device cleanup rules for Microsoft Intune

As an IT Administrator you want to keep your IT environment clean and tidy and the same goes for Microsoft Intune.

By default all devices that has been inactive or stale and hasn’t checked in for over 270 days will automatically been removed from the console.

In the latest update for Microsoft Intune dated July 2, Microsoft included a new feature, Device cleanup rules:.

New rules are available that let you automatically remove devices that haven’t checked in for a number of days that you set.

 

You will find it in the Intune pane, select Devices, and select Device Cleanup Rules:

By default, this is not enabled, so you need to change it to Yes and specific the numbers of days between 90 and 270 that suites your company’s policy and requirements.

If nothing is changed or you remain it set to No, it will use the default 270 days:



App Protection Policies for managed and unmanaged devices in Intune

In the latest update of Microsoft Intune, you now have the option to target App protection policies for Mobile apps if the device is Intune managed or if its unmanaged.

The two options that for now is available, if you select not to target all app types are:

  • Apps on unmanaged devices
    Unmanaged devices are devices where Intune MDM management has not been detected.
  • Apps on Intune managed devices
    Managed devices are managed by Intune MDM and have the IntuneMAMUPN app configuration settings deployed to the app.

With this new update, you are now able to create required settings for devices that are fully managed by Intune and separate policy for devices not managed by Intune.
For example you could allow saving files locally on devices managed by Intune and only allow saving to OneDrive or SharePoint (which is protected by App protection policies) on devices not managed by Intune.

If you are interested in learning more about App Protection Policies, you read more on docs.microsoft.com or drop a comment below!



Block external access for Service Accounts using Conditional Access in Azure AD

Conditional Access in Azure Active Directory is normally used for users and administrators to secure and control company data in Office 365 and Azure, but what about Service Accounts? Aren’t they a potential security risk?

Using Service Accounts for scripts and other tasks related to Office 365, Azure and Azure AD is a normal practice along companies, sometimes the accounts has full administrative permissions (Global Admin for Office 365, Owner of a subscription/resource group in Azure) and sometimes the accounts has delegated privileges but they all have more permissions than a regular user.

In this post we will cover how you can use Conditional Access to block sign-ins from service accounts outside the company main datacenter to make sure they are only used on servers located on networks that the company has control over.

  1. Open portal.azure.com and go to Azure Active Directory and Conditional Access under Security
  2. Go to Named locations and Add the external IP address of the data center(s) that should be allowed for the service accounts to sign-in from.
  3. Create a new policy and name it “Block external access for service accounts
  4. Select the Service Accounts or an Azure AD Group, in our case we use a groups that will contain all the service accounts
  5. In Cloud apps, select All cloud apps
  6. For Conditions, select Locations and Configure. Select Any location in the Include tab
  7. Also in Conditions and Locations, select the Exclude tab and select the location of the data center added in step 2.
  8. For Access, go to Grant and select Block access
  9. Select On for Enable policy, and verify all settings before creating it.
  10. The policy should now look like the following:
    Conditional Access policy - Block external access for service accounts

    Conditional Access policy – Block external access for service accounts

     

You can find out more about Conditional Access on docs.microsoft.com:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal 



Double-hop configured with Citrix Receiver inside a published desktop

 

We started a new project with one of our clients creating a new MCS master with Windows Server 2016. One of their most critical business applications do not support Windows Server 2016 with their current version of the application. In the best of world it woulds, we would just update the application, but sometimes this is just not possible or an option. One of our ideas to solve this was to create a second master with Windows Server 2008R2 and publish the application in the Windows Server 2016 start menu with Citrix Receiver. I will guide you below how we managed to get this to work very smoothly.

 

The first thing you will want to do is to install Citrix Receiver on to the Windows Server 2016 Master. If you installed Citrix Receiver with the VDA-agent, you may skip this step. If not, you must install Citrix Receiver using below parameters:

 

After this you will want to create a new GPO, apply it to all your Windows Server 2016 Targets and configure the following settings:

When the user logs in we want Citrix Receiver to start immediately and connect to the StoreFront. Since we are using redirected start menus for all users we published the following icon in the ”startup” folder.

Starting Citrix Receiver with the tag ”ipoll” will contact the server to refresh application details, but if no authentication context is available, prompt the user for credentials. You may read more about the Citrix Receiver tags here.

 

The next thing you will want to do is to log in with a test user. Citrix Receiver should now start for the user in the background and connect to the StoreFront. Log in as an administrator to the session host and browse to ”HKEY_USERS\{SID_FOR_TEST_USER}\Software\Microsoft\Windows\CurrentVersion\Uninstall”. You may now see all published applications as keys.

You’ll want to focus on the registry setting ”LaunchString”. Copy the value in ”LaunchString”. It should look something like below.

 

This string is unique for every application. This string is not unique for every user. We will want to use this string with Citrix Receiver.

 

Optimal would of course be to publish a shortcut in the redirected start menu, but since the string is to long the shortcut is capped with max characters. We must therefore create a script like below.

 

Browse to the redirected start menu and create a shortcut with target like below.

When the user logs in to the session and launches the application it should start from the Windows Server 2008R2 machines like below.

 

Hope this works as well for you as it does for me. Give me a comment below if you have any problems.