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.



Choosing ”HTML5 Receiver” vs ”Native Receiver” dynamically through Netscaler Rewrite Policies

After a user has authenticated on a NSGW vServer, the user will either be prompted to select which Receiver Type (HTML5 vs Native) he/she wants to use, or a choice will be made automatically depending on how well the user’s web browser manages to detect a local Citrix Receiver install. See below picture for an example of the prompt I’m referring to.

You can however get rid of below prompt, and at the same also have a mechanism that selects which Receiver Type that should be for a particular user or scenario. This is achieved through Netscaler Rewrite policies.

How does it work?

In a normal scenario, after the Receiver Type has been selected (either automatically or by user), then the cookie ‘CtxsClientDetectionDone=true’ will be created in the user’s web browser. If Native Receiver has been chosen, then the cookie ‘CtxsUserPreferredClient=Native’ will also be created. By using Rewrite Policies we can create these two cookies by ourselves for the user, and therefore suppress the prompt for the user and automatically choose which Receiver Type to use.

If HTML5 should be used, then we only want to apply the Rerwite policy ”RWP-RES-DISABLE-RECEIVER-CHECK” to suppress the prompt. When Netscaler sees that the cookie ‘CtxsUserPreferredClient’ Cookie is missing, it will default to HTML5 Receiver (this is dependent on your Storefront configuration – see further down). If we want to force the Native Receiver, we also apply the rewrite policy RWP-RES-SET-NATIVE-RECEIVER” to create the cookie ‘CtxsUserPreferredClient=Native’.

In below scenario, I have defined an Expression for my Rewrite Policy ‘RWP-RES-SET-NATIVE-RECEIVER’ to only apply if the user is connecting from IP subnet 10.240.5.0/24. You can also use ”HTTP.REQ.HEADER(\”User-Agent\”).CONTAINS(\”Chrome\”)” to only apply it to Chrome Users, or use most other type of Expressions. I tried to use HTTP.REQ.USER.ATTRIBUTE(1) and HTTP.REQ.USER.IS_MEMBEROF(\”GroupName\”) expressions, but it seems that these expressions will always evaluate to false for a Rewrite Policy bound to a VPN vServer, so they don’t work, which is a shame.

 

 

For the choice between Native Receiver and HTML5 Receiver to work, you will need to configure your Storefront so that both HTML5 and Native Receivers are possible, like below picture. If you configure ”Always use Receiver for HTML5” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then it doesn’t matter that the cookie ‘CtxsUserPreferredClient=Native’ exists. Similarly, if you configure ”Install locally” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then Native Receiver will always be used.

If you want want the dynamic choice between HTML5 and Native Receiver, then don’t use ”Use Receiver for HTML5 if local Receiver is unavailable” and only create the ‘CtxsClientDetectionDone’ cookie to suppress the unnecessary prompt for the user.

Feel free to email me at rasmus.kindberg@xenit.se if you have any suggestions or questions related to this blog post.



Automate tasks with use of XenServer Powershell Module

Working with backups of your virtual machines is obviously essential. Working with exports in XenServer can some times be time consuming, particularly with bigger virtual disks attached to your virtual machine. In this scenario I will show you an alternative to manually export via XenCenter, by doing it with Powershell to an remote server using XenServer Powershell module.



Flickering Desktop Icons and re-directed folders

This blog post will only cover a scenario with Microsoft Windows Server 2016 Remote Desktop Services (RDS) and re-directed folders where flickering icons appear. Other solutions may apply to different scenarios.
Since the release of Windows 10 / Server 2016 and their different releases 1607, 1703, 1709 and 1803 there has been several issues regarding flickering icons on the Start-menu, in File Explorer and taskbar.

SCENARIO

During the deployment of Citrix Virtual Apps and Desktops 7.15 on Windows Server 2016 with published Desktops and re-directed Desktop folder, users could experience that the desktop icons kept flickering continuously. The more shortcuts, folders or files on the Desktop the more prevalent the issue was. Constantly blinking icons on the desktop looked like refreshing the desktop with F5 or Ctrl+R and would also flash when browsing network shares.

My first thought was to activate ”Always show icons, never thumbnails” in Folder Options since there seemed to be a constant query to network shares where the re-directed Desktop folder resided.

File Explorer - Options

File Explorer – Options

File Explorer - Always show icons

File Explorer – Always show icons

INVESTIGATION

The moment I clicked on View in Folder Options the desktop icons ceased flashing in my session. Dwelling deeper with Procmon investigating what actually happens when opening View tab in Folder Options I found out that explorer.exe queries a registry key in the users HKEY_CURRENT_USER registry. If the registry entry does not exist it will be created.

  • HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
Explorer query and creation of registry key

ProcMon – Explorer.exe query and creation of registry key

SOLUTION

With the knowledge that the registry key was missing and creating they key would stop the icons from flashing for users on Windows Server 2016 RDS, the appropriate solution was to use Group Policy Preferences (GPP) that created the registry key for users during logon (run in logged-on users’s security context) and apply it to Windows 2016 RDS servers.
Gorup Policy Preferences - User Configuration - Registry

Gorup Policy Preferences – User Configuration – Registry

Apply to Current User

Apply to HKEY_CURRENT_USER and set Key Path

Run in logged-on users security context

Run in logged-on users security context

Step 1: Create a USER GPP that will be applied to affected targets

Step 2: Create a Registry Item

Step 3: Add registry key

  • Hive: HKEY_CURRENT_USER
  • Key Path: SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
  • Tab Common: [v] Run in logged-on user’s security context (user policy option)

If you have any questions regarding above solution, or ideas on how to handle above in a better way, please contact me at viktor.glinski@xenit.se or post a comment below.