After I completed a recent upgrade of Windows 10 to 1803, I noticed that my English (United Kingdom) language had been joined by English (United States) and that I couldn’t remove this from the system.

After a bit of research I came across the following article that demonstrated how the additional language can be removed using PowerShell –

Nice and cleanly I no longer have the “ENG” menu in my task bar to switch to a language I don’t need.

A lot of my work recently has been working with Microsoft Intune to utilise Microsoft Modern Management constructs and principles to deliver a cloud first approach to provisioning new Windows 10 endpoints for an organisation.

Since Microsoft has migrated Intune management from the classic interface to the Azure Portal, the ability to execute installers for legacy line of business applications has been reduced. The idea is that the modern workplace is consuming data via apps from an app store and this is evident in Microsoft’s support for the Microsoft Store for Business and Universal Windows Platform .appx package support in Intune however this is not always feasible in most workplaces. There are still legacy line of business applications that require an MSI or EXE based installer and whilst Intune will support Line of Business installers that are MSI based there is again a limitation that the MSI must contain all the code required to install the application. There is currently no support for EXE based installers in the Azure Portal for Intune.

Back at Microsoft Ignite 2017, Microsoft announced the availability of the Intune Management Extension and the support to execute PowerShell scripts on Windows 10 Endpoints via Microsoft Intune (Read More). This got me thinking about how to extend the functionality of Microsoft Intune to deliver a more traditional (MDT / SCCM) provisioning process for legacy applications on modern managed Windows 10 devices.

If you could store your legacy line of business applications in a web accessible location (with appropriate security controls to prevent unauthorised access) you could then utilise the Intune Management Extension and PowerShell scripts to download the application install payload to a temporary location and then execute the payload to overcome the limitation of the Intune portal.

Looking around the Internet I came across this blog post by MVP Peter van der Woude which integrates the Chocolatey package manager and Intune. With a bit of reworking I amended the PowerShell code to download and install the AEM agent onto a target machine.

Save the PowerShell script and then add to Intune as outlined in Peter’s blog post and wait for the code to execute on your endpoint. The process can be extended to run any executable based installer.

Whilst this is a fairly simplistic example, the concept could be extended to download a compressed archive, extract and then execute the installer as required.

As I deploy more and more instances of Microsoft Intune I am having to  onfigure managed applications for Android and iOS enrolled devices. Whilst the iOS app store has been neatly integrated into the Azure portal, Android apps need to be added by their relevant App URL (frustrating and something I hope that Microsoft / Google can fix in the near future).

When configuring the mobile app and app protection policies it can be useful to have the correct Microsoft suite (Outlook, Word, Excel, PowerPoint, OneDrive, Skype for Business etc.) installed automatically on the end user device. The list below is hopefully a time saver to get to each of the applications without having to click through or search the Google Play store manually:

In the second quick article following my reporting requirement this time is to report on the enabled user accounts that have not logged in in the past X days. Again a quick Google came across the following article on WindowsITPro (Use Get-ADUser to Find Inactive AD Users)

I took the Search-ADAccount cmdlet and created some filters to exclude disabled accounts as well as enable a parameter to be passed with the script to specify the maximum age, in days, of a user account (default is 90 days)

Save the below script as Get-InactiveAccounts.ps1

To execute the script run .\Get-InactiveAccounts.ps1 to report on accounts older than 90 days or use the InactiveDays parameter to specify the age of accounts to report (eg .\Get-InactiveAccounts.ps1 -InactiveDays 180)

As part of some recent work to assist a client with reporting on their active users and the dates those users last changed their passwords I evolved a script written by Carl Gray here (PowerShell: Get-ADUser to retrieve password last set and expiry information) to generate a short PowerShell script that will report the enabled Active Directory users and the date that they last set their password.

Copy the code below and save on your server as Get-PasswordLastChange.ps1 and then run from the command line. Script will produce a CSV file and save it in the same directory as the script

I have been working on an issue for one of my clients where they have migrated email from an on-premise Exchange server to Microsoft Office 365. The migration was handled using a third party migration tool to synchronise email content into their Office 365 tenant, something that didn’t go smoothly and not wholly relevant to this posting. The major thing that wasn’t fully setup was the synchronisation between their existing on-premise Active Directory and their 365 tenant and users struggled initially with passwords that were not in sync between the two platforms. One thing that did happen however was that the Exchange server was decommissioned and any Exchange attributes removed from the Active Directory user accounts.

Looking into this I started by upgrading the installed version of DirSync to the latest release from Microsoft (click here) which automatically detected the previous installation and upgraded it to the latest release. As described in upgrade guide I completed the initial configuration and provided the following to the wizard:

  • Office 365 administrative login,
  • my Active Directory details,
  • the fact that it is not a hybrid deployment (remember Exchange has already been uninstalled),
  • that I wanted to sync passwords and
  • to not perform an initial sync (I need to troubleshoot what hasn’t been working).

I opened the not so easy to find Synchronisation Service Manager (C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell) and checked the configuration of the data to be synchronised.

We are synchronising our users based on their location in Active Directory and have created two Organisational Units (OUs) under two separate User OUs within our directory only one of these has been selected at this stage.

The user was showing up and the synchronisation log was showing success messages. I updated the Department attribute for the user within Active Directory and forced a sync to office 365, no errors reported in the Sync Manager and the Office 365 user was updated correctly. This seemed so simple so I informed my client we would enable the changes this week and everything would go back to one password and, apart from the shortcoming of Microsoft Outlook not participating with the Single Sign-On that the rest of Office does, users would be happy.

Or so I thought until I came to actually enable the remainder of the users…

I opened Synchronisation Service Manger, browsed to Management Agents and edited the Active Directory Connector, edited the Containers I wanted to sync and clicked OK only to be given the message:

Join/Protection validation error
‘publicFolder’ is no longer listed in the list of selected object classes

Googling didn’t come up with much more than this forum post ( which was unanswered at the time.

Looking through the options I found that under Select Object Type the publicFolder wasn’t listed so after clicking Show All, scrolling down a long way I enabled it and was able to save the update configuration

publicFolder Object Type

First hurdle out the way I moved a user into my new OU and forced another synchronisation… which failed

Attribute Value must be unique


Clicking on the error I was redirected to a Microsoft KB article (KB2647098). Reading through the article I knew there were no duplicate accounts either locally in my AD domain or in the 365 tenant so I started to look into the proxyaddresses to see if Exchange had left something in place when it was removed from the network. When I looked in ADSIEdit at the user in question I found there were no proxyaddresses listed at all:

Checking the one synchronised user I noticed that they did have the proxy addresses listed so I added them manually in the format

Saving this and re-running the sync gave me a success, my user was now showing as synchronised with Office 365. I added another couple of users but this time, when I synchronised I received a different error message


I checked the accounts were enabled both in Office 365 and in Active Directory, restarted the DirSync service to no avail. After looking at this and a handful of other users I could see that this was going to take a while to complete manually so needed to automate this in some way. Rather than spend some time researching how to write the appropriate PowerShell commands to complete this change I switched to my trusty friend ( I have used many times in the past to update attributes in bulk within Active Directory.

For those of you that haven’t used it is a very competent tool at modifying the attributes of a number of AD objects in bulk.

Extract the contents of the download and run the executable then click on Modify Attributes when prompted


Select your Domain and preferred Domain Controller from the menu on the left, click the green icon and then browse to your OU to modify.


Click on Add to List at the bottom to add the discovered objects, select the ones you wish to modify and click on Next


On the email addresses tab choose Add SMTP Address and enter the email address in the format you want to use. Set Primary and update the General tab as well then click Go.

At this stage the tool will update the AD attributes for the list of objects selected earlier, output a popup with the status of any failures as well as write an XML based log file to the directory the executable ran from. Review any errors and then continue to add any other addresses


Here I have added an address that matches their UPN login to match the configuration I can see for my Office 365 users.

Now that these have been run against all the AD accounts that need to synchronise I restarted the DirSync services once more and completed my sync without issues.

The conclusion from all this is to make sure that everything is in place to synchronise your Active Directory and Office 365 tenant *before* decommissioning Exchange but also that if you are in this situation that you make use of tools such as to save the hassle of editing all the records by hand.

New Job, Updated blog

Posted by mattywhi | IT

After eight years working at Wavex I have taken the decision to move on for a new career challenge and I am now a Senior Infrastructure Engineer at IT Lab. The past eight years have been a very good learning experience and I have developed from a young and inexperienced Service Desk Engineer into a more confident and technical IT Professional with the ability to communicate on a technical and commercial level to explain the problem and solution in a given situation.

As part of this change I have decided to try and remove some of the more juvenile aspects of my website and tidy up some of the blog posts that were written before I started my professional career as I realised that many of these were inappropriate content for a modern audience. All the blog content has moved from the subfolder “blog” to the root of my website and I am hoping that as my new role develops that there will be new content added over the coming months to read.

Thank you to all those at Wavex for their time in the past and here’s to the future.


Having a Single Point of Failure (SPoF) on your network is never a desirable situation and recently I implemented a multi-site set-up where each site had two internet connections and there was a requirement to enable the satellite office to connect to the head office at all times. Each site has a Juniper SSG5-SB firewall as well as a 10Mbit leased line primary Internet circuit and an ADSL backup.

With the Juniper SSG firewalls it is possible to use Policy Based VPNs to maintain multiple tunnels and have the firewalls switch between these as required however you end up with four policies on each firewall and you cannot tell from looking at a routing table where the traffic is flowing. In this instance I decided to make use of OSPF to dynamically route the traffic depending on the availability of the VPNs at each site.

The first thing we need to do in order to implement this is to put each Internet connection into its own Virtual Router so they can run independently of each other.I have covered this in a recent blog post which you can read here.

Once you have the two firewalls setup with each Internet connection in its own virtual router we need to setup the VPNs. This is done with a new Zone in the trust-vr and we will need four numbered tunnel interfaces on each firewall.

On the second site firewall you will need to repeat the commands but using the other IP address in the /30 in each case.

Now we need to setup the VPN tunnels. You may want to change these based upon your requirements however I have used these settings regularly and they work well. NB you will need to apply similar settings on the Site-B firewall with the various endpoint addresses for SiteA

From the GUI you should be able to check that these have come up by going to VPN -> Monitor Status.

We now need to enable OSPF on the trust-vr and configure the interfaces to communicate using OSPF. This should be completed on both the primary and secondary site firewalls.

You can check the OSPF status by running the following command

Finally we need to setup policies to allow traffic to flow across the VPN between the two sites.

To test this you need to take down the Internet connections one by one and watch the routing table update on each firewall.
You should now see all four IPSec VPN Tunnels show as active and the route between sites will be via the Layer-3 tunnel interface for the relevant tunnel.

I have been bitten enough times when my ssh session to my JunOS switch or router has been disconnected because it was idle and then when I reconnect get the warning to say that another user is editing the configuration.

The easiest thing to do is to log out the other session once you have reconnected to the device by using the PID of the stale session (in this case 28439) with the following command:

You should now no longer see that message when you log back into the switch.

I’ve recently been configuring a new Citrix XenApp 6.5 farm for one of my clients and as part of the deployment was looking through some articles on configuring the farm settings when I discovered the following post in Gerrish’s IT Blog about enabling the enhanced user interface features available with XenApp 6.5 (XenApp 6.5 – Enhanced Desktop Experience)

Alongside the implementation of a standardised user interface the post also explains how Citrix can automatically create some GPO templates to lock down the server farm so the users are not able to perform tasks they shouldn’t be able to do. These policies will need to be tweaked to match the requirements of your particular environmetn but provides a strong starting point for configuring and standardising your Citrix farm.