Category: Microsoft

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.



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 



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.



Specific computer model not joining the domain.

I recently had an issue with a specific computer model not joining the domain. The Task Sequence had not been updated for a while, and we had not done any significant changes to the environment. With other computers working flawlessly, we had issues with a HP EliteDesk 800 G3 DM 35W not joining the domain for some unclear reason. This was the start of an interesting discovery.

The issue began when this EliteDesk 800 G3 wouldn’t join the domain. Usually when a Task Sequence finishes, the computer reboots and you see a login screen, stating the domain and asking for credentials, as shown in this picture.

Usual image after a successful Task Sequence

This time the EliteDesk didn’t show any domain, just asking for local Administrator credentials. My first guess was network drivers, so I started by updating the boot image with fresh network drivers for EliteDesk 800 G3. Even with up-to-date drivers the computer wouldn’t join the domain. I started going through the SMSTSLog, BDD.log, checked if something had failed during the Task Sequence. No errors were found. But still, the computer would not join the domain.

I started digging deeper and went through the “panther\UnattendGC\setupact.log” and the “debug\NetSetup.log”. It was here where I started to find some interesting issues.

We have an environment built around an OU structure based on location and computer type (desktop, laptop or virtual machine). The ComputerTypeOU property is saved in to a variable used in the Task Sequence. What OU the computer is added to is decided in the CustomSettings.ini-file. 

In both the setupact.log and NetSetup.log I found out that no value was saved in the “%ComputerTypeOU%”-variable.

NetSetup.Log of EliteDesk 800 G3 DM 35W

My initial thought was that the log prints the string without any value connected to the variable, but after going through the same logs on a newly installed computer, that had no issues joining the domain, I quickly found out that I was wrong. The variable should definitely contain the value generated by the CustomSettings.ini file.

NetSetup.Log of EliteBook Folio 9480m

As shown in the first image, the EliteDesk 800 G3 did for some reason not receive any value to this variable. I started going through logs once more, trying to find out why this computer was unable to fetch the required value.

Since we unfortunately do not have an OU named “%ComputerTypeOU%” in the domain, and the Join Domain-account was unable to create one, the computer did not join the domain because of the account used in our Task Sequence having insufficient rights.

But why this variable was missing its value was the main question. I started going through logs again, and this time I had something to look for instead of searching for the unknown. The BDD.log gave me a good overview of all the client properties. I compared a domain joined client with the EliteDesk 800 G3. Here I stumbled upon an interesting fact. The EliteDesk did not report as a laptop, a desktop nor a server, as shown below.

BDD.Log of a EliteDesk 800 G3 DM 35W

BDD.Log of a EliteBook Folio 9480m

 

Since the EliteDesk 800 G3 did not report any of the values needed for our structure, the solution was to add Model to the Priority list and associate EliteDesk 800 G3 with the “ComputerTypeOU”-property set to workstations.

After adding the Model property to the CustomSettings.ini file, the EliteDesk 800 G3 joined the domain flawlessly after running a Task Sequence.

This might not be the best solution to this matter, but it sure is a practicable fix. If anyone has a preferable solution, feel free to email me at johan.nilsson@xenit.se



Upgrade Task Sequence (1803) with BitLocker active

With the new 1803 feature update for Windows 10 we got some new and exciting commands for the Windows Setup that we can use in a upgrade task sequence in SCCM to be able to upgrade without suspending BitLocker. For more information about the 1803 feature update, please see this blogpost.

With these new Setup commands you can set a specific value in your task sequence that will try to keep BitLocker active or force it to be active during the upgrade. You can also use the AlwaysSuspend option but as the word explains this will actually suspend BitLocker and that’s not what we want in this post. The different commands are as follows:

  • /BitLocker TryKeepActive
  • /BitLocker ForceKeepActive
  • /BitLocker AlwaysSuspend

In your upgrade task sequence you need to set the variable OSDSetupAdditionalUpgradeOptions to one of the options above depending on how you want the upgrade to handle BitLocker. In this scenario we are using the /BitLocker TryKeepActive value that will attempt to do the upgrade without suspending BitLocker, but if the upgrade fails, Windows Setup will suspend BitLocker and complete the upgrade.

Please note that there are some requirements to get this setup to work.

  • The device being upgraded should be Windows 10 1709 or higher.
  • The Windows device needs to be using Secure Boot and have a TPM.
  • BitLocker needs to be using a TPM protector only.
  • The user profile folder can’t be on a separate volume that is also BitLocker protected.

 

If setup correctly you will find that the command line for the Windows Setup upgrade will add the /BitLocker TryKeepActive to it, as shown below. This can be viewed in the smsts.log.

 

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



Palo Alto introduces new feature to support Terminal Service (TS) Agent on Windows Server 2016

In the latest release of Palo Alto Networks Terminal Service Agent 8.1.1, we were introduced to a new feature where it is now supported to install the agent on Windows Server 2016.

This is a very welcome feature that a lot of us have been waiting for. There are no other features added to this version or the one before.

This release is also compatible with all the PAN-OS versions that Palo Alto Networks still support.

For more information see:

Where Can I Install the Terminal Service (TS) Agent?

Release Notes – Terminal Service Agent 8.1