As epitomised by the recent rebranding exercise Microsoft conducted with the product, I very much see Visual Studio Team Services/Team Foundation Server Azure DevOps becoming an increasingly dominant tool for development teams the world over. I came into the product after discovering its benefits from Ben Walker at a CRMUG meeting a few years back and, since then, the product has proved to be a real boon in helping me to:

  • Manage code across various .NET and Dynamics CRM/Dynamics 365 Customer Engagement projects.
  • Formalise the code review process, via the usage of pull request approvals.
  • Log and track backlogs across various project work.
  • Automate the project build process and deployment into development environments, allowing us to identify broken builds quickly.
  • Fully automate release cycles, reducing the risk of human error and potentially laborious late night working.

I really would urge any company carrying out some form of bespoke development, mainly with the Microsoft technology stack, to give Azure DevOps a look. Contrary to some of the previous biases that would creep in as part of Microsoft’s products, Azure DevOps is very much built with openness at its core, allowing you to straightforwardly leverage sections or the whole breadth of its functionality to suit your particular purpose.

When you start working with Azure DevOps more in-depth, it becomes obvious that having a general awareness of PowerShell will hold you in good stead. Although targeted towards more Microsoft-focused deployments, PowerShell becomes your go-to tool when working with Azure in particular. Recently, I had a PowerShell Script task that previously executed with no issue whatsoever on a Windows 10 self-hosted agent. The first thing that the script did was to define the Execution Policy, using the following command:

Set-ExecutionPolicy Unrestricted

(For the uninitiated, the above is an atypical requirement for all PowerShell scripts to ensure that you do not hit any permission issues during script execution.)

As stated already, this was all working fine and dandy, until one day, when my deployments suddenly started failing with the following error message:

Executing the script manually on the machine in question, in an elevated PowerShell window, confirmed that it was not an issue on Azure DevOps side:

Well, this is one of those occasions where the actual error message tells you everything you need to know to get things working again. Whether something had changed on the machine or not as part of an update, it was now necessary to modify the PowerShell command to include the -Scope option outlined above. Therefore, the script should resemble the following:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

We can then confirm that the script no longer errors when being executed on the machine in question:

And, most importantly, the release pipeline in question now completes without any error šŸ™‚

Perhaps its just me, but often in these types of situations, you can overlook the completely obvious and find yourself going down the rabbit hole, chasing a non-existant or grandiose solution to a particular IT problem. As this example clearly demonstrates, sometimes just reading the error message you are presented with properly can reduce a lot of wasted effort and allow you to resolve a problem faster than expected.

If you are heavily involved with the management and deployment of Office 365 Click-to-Run installation packages on a daily basis, the chances are that you have come across all sorts of weird and wonderful error messages throughout your travels. Although I am admittedly a novice in this area, I know there is oft the requirement to resort to registry modifications or similar to achieve certain kinds of management tasks, along with a whole list of other quirks that can test the patience of even the most ardent of IT professionals and frustrate what may appear to be simplistic Office 365 deployments.

Case in point – the installation of the downloadable Click-to-Run Office 365 installation package (available from the Office 365 portal) can be complicated when installing it via the default Administrator account on a Windows machine. When attempting to do this, either by double-clicking the executable file or executing itĀ usingĀ Run as administrator privileges, you may get the following error message displayed below:

The error can occur in any version of Windows, up to and including Windows 10 1803 Build. The issue appears to pertain to the default Administrator account that is created on the operating system and can be observed occurring when creating a new Windows 10 Virtual Machine on Azure. It’s possible that the error may also occur in desktop versions of the operating system, depending on how the initial local administrator user account is deployed. There are a couple of ways to resolve this error, depending on your preferred method, familiarity with working with the inner engines of Windows and your inclination towards either a quick or “proper” solution.

The quick and easy solution

This route involves the creation of a new user account on the machine, which can then be logged into and used to install the application via User Account Control elevated privileges. The steps to achieve this are as follows:

  1. TypeĀ Windows + RĀ on the start menu to open the Run box.
  2. EnterĀ lusrmgr.mscĀ in the Run box and hit enter. This will open theĀ Local Users and GroupsĀ Microsoft Management Console (MMC) snap-in.
  3. Right-click on theĀ Users folder and selectĀ New User
  4. Create a new user account with the required details and password. Ensure that the account is not disabled via theĀ Account is disabled button and click Create to…well…create the account. šŸ™‚
  5. Log out of Windows and log back in as the new user. When attempting to run the installation package again, you should be (correctly) prompted to enter Administrator credentials via the UAC control dialog and the installation should start successfully.

The proper solution

Although the above steps are perfectly acceptable and straightforward to follow if you are in a rush, they do not address the underlying problem with the default Administrator account – namely, that it will have issues installingĀ anyĀ application that requires elevated privileges. In most cases, where an application requires installation onto a machine, it is generally better to login as the Administrator user account as opposed to relying solely on the UAC elevation prompt. As a consequence, the most ideal solution to save you from any future hassle is to fix the issue with the default Administrator account permanently.

Following some research online and testing on my side, I found this article which goes through the steps that will successfully address the problem and enable you to install Office 365 – and any other program – without issue. In my specific example, I had to follow the instructions listed in Method 2 and 3, followed by a restart of the machine in question, before I was able to install Office 365 successfully. Although the steps involved are a little more complex and error-prone, the article does provide clear instructions, along with screenshots, to help you along the way.

Conclusions or Wot I Think

I recently attended a Microsoft Partner training day covering Microsoft 365 Business and Enterprise and the topic of Office 365 came up regularly, as you can imagine. The deployment settings afforded to you via Microsoft 365 let you perform automated actions in a pinch, with perhaps the most common one being the removal of any local administrator privileges when a new machine is deployed using your organisation’s chosen template. As our instructor pointed out, this is incompatible with how Office 365 installations operate; because, as we have seen, full administrative privileges are required to install the software. We, therefore, find ourselves in this strange state of affairs where the Microsoft 365 solution as a whole is in a glass half full (or half empty, if you are feeling pessimistic) situation and, more generally, Office 365 deployments are hampered due to requiring local or domain level Administrator privileges. I would hope that, eventually, Microsoft would look to providing an installation package of Office that does not require such extensive permissions to install. Doing this would kill two birds with one stone – it would help to make the deployment of all the components of Microsoft 365 a breeze whilst also avoiding the error message discussed in this post. Here’s hoping that we see this change in the future to avoid interesting little side-journeys like this when deploying Office 365.