BM-Bloggers – The aggregate of the blogs of Black Marble Staff

13th August 2019

Authentication loops swapping organisations in Azure DevOps

I have recently been getting a problem swapping between different organisations in Azure DevOps. It happens when I swap between Black Mable ones and customer ones, where each is back by different Azure Active Directory (AAD) but I am using the same credentials; because I am either a member of that AAD or a guest.

The problem is I get into an authentication loop. It happens to be in Chrome, but you might find the same problem in other browsers.

It seems to be a recent issue, maybe related to MFA changes in AAD?

I used to be re-promoted for my ID when I swapped organisations in a browser tab, but not asked for further authentication

However, now the following happens

I login to an organisation without a problem e.g https://dev.azure.com/someorg using ID, password and MFA
In the same browser window, when I connect to another organisation e.g. https://dev.azure.com/someotherorg
I am asked to pick an account, then there is the MFA challenge, but then go back to the login
…. and repeat.

The fix is to go in the browser tab to https://dev.azure.com. As you are already authenticated you will be able to sign out, then all is OK, you can login again.

The other options is to make even more use of Chrome People; one ‘person’ per customer, as opposed to my current usage on one ‘person’ per ID

25th July 2019

You can’t use Azure DevOps Pipeline Gates to check services behind a firewall

I have recently be working on a release pipeline that deploys to a server behind a corporate firewall. This is done using an Azure DevOps private build agent and works fine.

As the service is a basic REST service and takes a bit of time to start-up I though a gate was a perfect way to pause the release pipeline until service was ready for the automated tests.

However, I hit a problem, the gates always failed as the internal server could not be resolved.

After a bit of thought I realised why. Gates as actual agentless tasks, they don’t run on the agent but on the server, so are outside the firewall. They could never connect to the private service without ports being opened, which was never going to happen.

So at this point in time I can’t use gates on this pipeline. Any similar logic to do the same job would have to be developed as scripts I can run on an agent.

7th June 2019

Surface Pro 3 Type Cover Not Working After Windows 10 1903 Image Applied

Symptoms:

Following imaging with Windows 10 1903 using Configuration Manager OSD, the Type Cover doesn’t work at all (keyboard, trackpad).
When rebooting the machine, the keyboard and trackpad both work when in the BIOS.
When imaging the machine, both the keyboard and trackpad work in Windows PE.

The Surface Pro 3 was imaged and then patched up-to-date and the most recent Surface Pro 3 drivers available from Microsoft were applied, however the issue persisted.

To correct this issue, complete the following steps:

Open Control Panel and navigate to ‘Hardware and Sound’ and then ‘Devices and Printers’.
Select the Surface Type Cover and open the properties for this device. Select the ‘Hardware’ tab on the dialog:
In turn, select each of the device functions shown in the list and click the ‘Properties’ button:
Click the ‘Change Settings’ button, then from the dialog that is shown select ‘Uninstall Device’. If offered the option to delete the driver software for this device, ensure that the checkbox to do so is selected (not all devices offer this option) and click ‘Uninstall’:
Ensure this has been completed for all device functions shown in the list, then close the main properties dialog.
Open the Device Manager for the computer, right-click the computer name at the top and select ‘Scan for Hardware Changes’.
Expand the firmware section within Device Manager. For each of the items shown, right click the item and select ‘Update Driver’. Click ‘Search automatically for updated driver software’ from the dialog that is shown:

Note that if you’ve installed the latest Surface Pro 3 drivers, none of the firmware items shown are likely to be updated, but attempt to update each item. If you’ve not installed the latest drivers, the firmware list may have more generic titles which will be updated as the appropriate firmware is applied.
Repeat the process of updating the driver for each item under the Keyboards section of the Device Manager. Note that even with the most recent driver pack installed, all of these entries on the device I was working on were the generic ‘HID Keyboard Device’. We don’t know which one of the keyboard devices listed is the Type Cover, however when you get to the correct one you’ll that the driver that is installed is listed as ‘Surface Type Cover Filter Device’:
As soon as this driver is installed, the Type Cover should start working again. In my case no reboot was required.

6th June 201914th June 2019

Review of ‘Azure DevOps Server 2019 Cookbook’ – well worth getting

It always amazes me that people find time to write tech books whilst having a full time job. So given the effort I know it will have been, it is great to see an update to Tarun Arora and Utkarsh Sigihalli’s book ‘Azure DevOps Server 2019 Cookbook’.

Azure DevOps Server 2019 Cookbook - Second Edition

I do like their format of ‘recipes’ that walk through common requirements. I find it particularly interesting that for virtually each recipes there is an associated Azure DevOps Extension that enhances the experience. It speaks well of the research the authors have done and the richness and variety of the 3rd party extensions in the Azure DevOps Marketplaces

I think because of this format there is something in this book for everyone, whether new to Azure DevOps Server 2019 or someone who has been around the product since the days of TFS 2005.

In my opinion, it is well worth having a copy on your shelf, whether physical or virtual

23rd May 2019

Azure DevOps Repos branch build policies not triggering when expected in PRs – Solved

I recently hit a problem with builds triggered by branch policies in Azure DevOps Repos. With the help of Microsoft I found out the problem and I thought it worth writing up uncase others hit the issue.

Setup

Folders

Assume you have a Git repo with source for the UI, backend Services and common code in sub folders

/ [root]
     UI
     Services
     Common

Branch Policies

On the Master branch there are a policies of running

one build for anything in the UI folder/project or common folder/project
and a different build for anything in the Services folder/project or common folder/project

These build were filtered by path using the filters

/UX; /Common
/Services; /Common

The Issue

I discovered the problem by doing the following

Create a PR for some work that effects the UI project
As expected the UI build triggers
Update the PR with a second commit for the Services code
The Service build is not triggered

The Solution

The fix was simple it turns out. Remove the spaces from the filter paths so they become

/UX;/Common
/Services;/Common

Once this was done the builds triggered as expected.

Thanks again to the Azure DevOps Product Group for the help

23rd May 2019

Regex issues in Node

I have been trying to use Regex to select a block of an XML based .NET Core CSPROJ file, and yes before you say know I could use XPATH, but why am not is another story.

I was trying to use the Regex

content.match(/<PropertyGroup>((.|n)*)</PropertyGroup>/gmi)

The strange thing was this selection string worked in online Regex testers and in online Javascript IDEs, but failed inside my Node based Azure DevOps Pipeline extension.

After much experimentation I found that the following line worked

content.match(/<PropertyGroup>([sS]*?)</PropertyGroup>/gmi)

Well that a a good few hours of my life I won’t get back. No idea why Node handles the wildcards differently

30th April 2019

A fix for Error: SignerSign() failed." (-2146958839/0x80080209) with SignTool.exe

I have spent too long recently trying to sign a UWP .MSIXBUNDLE generated from an Azure DevOps build using the SignTool.exe and our code signing certificate. I kept getting the error

Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-2146958839/0x80080209)

From past experience, SignTool errors are usually due to the publisher details in the XML manifest files (in this case unpack the bundle with MakeAppx.exe and look in AppxMetadataAppxBundleManifest.xml, and also check the manifest in the bundled .MSIX files) does not match the subject details for the PFX file being used for signing.

Or so I thought…..

Turns out you can get this error too if you use the wrong version of the SignTool, but it give no clue to this fact.

So the top tip is …

Make sure you use the SignTool.exe from the same folder as the MakeAppx.exe tool. In my case in “C:Program Files (x86)Windows Kits10bin10.0.17763.0x64”

Once I did this, after of course updating all the manifest files with the correct publisher details, I was able to sign my bundle as I wanted.

26th April 2019

Migrating a GUI based build to YAML in Azure DevOps Pipelines

Introduction

I use Azure DevOps Pipelines for the build and release of my Azure DevOps Pipeline extensions, I previously detailed my process here .

For a good few months now YAML builds have been available. These provide the key advantage that the build is defined in a YAML text file that is stored with your product’s source code, thus allowing you to more easily track build changes. Also bulk editing becomes easier as a simple text editor can be used.

I have been putting off moving my current GUI based builds for as there is a bit of work, this post document then step.

Process

Getting the old build content

First I created a new branch in my local copy of my GitHub repo that stores the source for my extensions

I then created an empty file azure-pipelines-build.yaml the same folder as the root of the extension I was replacing the build for. I created the empty text file. I did this as the current create new build UI allows you to pick a file or a create one, but if you create one it gives you no control as to where or how it is named

In you existing build I then clicked the pipeline level ‘View YAML’

Note: Initially I found this link disabled, but if you click around the UI, into the task details, variables etc, it eventually becomes enabled. I have no idea why.

Copy this YAML into you newly created azure-pipelines-build.yaml file, committed the file and pushed it GitHub as the new branch.

Creating the YAML build

I then created a new YAML based build, picking in my case GitHub as the source host, the correct branch, and correct file.

This YAML contains the core of what is needed, but the build was missing some some items such as triggers, build number and variable.

I added

the name (build number)
the PR triggers to the YAML

to the .YAML file, but decided to declare my variables as they contained secrets within the build definition in Azure DevOps.

The final YAML file was can be viewed here

What I fixed in passing

In the past I used to package up my extensions twice, once packaged as private (for testing) and once as public. This was due to the limitation of the Azure DevOps Marketplace and the release tasks I was using at the time. Whilst passing a took the chance to change to only building the public VSIX package, but updated my release pipeline process to dynamically inject the settings for private testing. This was done using the newer Azure DevOps Extensions Tasks.

As I side note I had to upgrade to these newer release tasks anyway as the older ones had ceased to work due to using old API calls

Swapping in the new build into the release process

To replace the old GUI build with the new YAML build I did the following

Renamed my old GUI build and disabled this (the disable is vital else it continues to be triggered by the GitHub PRs, even if the triggers are removed in the build)
Renamed my new YAML build to the old GUI build name (not vital, but it felt neater)
Updated my release pipeline to pick the new YAML build as opposed to the old GUI build. Even though the names were the same, their internal IDs are not, so this needs to be swapped. I made sure my ‘source alias’ did not change, so I did not have to make other changes to my release pipeline.

Once this was done I triggered a new GitHub PR and everything worked as expects.

What Next

I have kept the old build about just in case there is a problem I have not spotted, but I intend to delete this soon.

I now need to make the same changes for all my other build. The only difference for from this process will be for builds that make use of Task Groups, such as all those for Node based extensions. Task Groups cannot be exported as YAML at this time, so I will have to manually rebuilding these steps in a text editor. So more prone to human error, but I think it needs to be done.

So a nice back burner project. I will probably update them as release new versions of extensions.

28th March 2019

SCCM OSD on Surface Pro 6

Today we attempted to re-image Rik’s new Surface Pro 6 using the usual set of task sequences that we have configured for all of the PCs that are in use, and hit an issue.

The task sequence failed (very quickly) with error 0x80070490. Looking at what was going on onscreen, it was obvious that the partitioning of the disk within the device was failing.

Initially I assumed that it was driver related and so pulled down the Surface Pro 6 driver pack from Microsoft, added it to SCCM and updated the boot media to include appropriate drivers. This didn’t solve the issue however.

Looking at the disk configuration, it became apparent that the disk number associated with the SSD within the Pro 6 was not the ‘0’ that I expected, but ‘2’ instead! It appears, following some reading that the ‘disk’ in this device, which is a 1TB drive, is actually two SSDs configured as a RAID 0 set, hence the disk number being ‘2’.

Copying the task sequence that Rik wanted to use to deploy the OS and software to the device allowed us to modify the disk number that would be used to ‘2’, which allowed the task sequence to complete successfully.

We have a couple of options available to us for deployment of these task sequences in the future:

Create an additional device collection and populate with the Surface Pro 6 devices to target the modified task sequence and keep a separate task sequence for deploying the OS to these devices, or
Use some conditional queries to determine whether we’re dealing with a Surface Pro which has two disks configured as RAID 0 and hence has a disk ‘2’.

The latter is the more elegant method and means that I won’t need to keep even more task sequences around.

To implement this, we can utilise a couple of WMI queries to determine whether we’re dealing with one of these devices:

SELECT * FROM Win32_ComputerSystemProduct WHERE name = “Surface Pro”

SELECT * FROM Win32_DiskDrive WHERE Index = 2 AND InterfaceType = “SCSI”

Both are in the standard rootcimv2 namespace.

Within the task sequence, the default UEFI partitioning step should target disk 0 and the options should look like this:

The Surface Pro 6 1TB UEFI partitioning step should target disk 2 and the conditions should have ‘all’ rather than ‘none’ in the IF statement.

16th January 2019

Configuring PowerChute Network Shutdown on Server Core

Everyone installing Hyper-V servers is installing them as Server Core servers, right? Smile

I recently hit an issue configuring APC’s PowerChute Network Shutdown (PCNS) software on a Server Core installation of Windows Server 1809 (the most recent release of the semi-annual channel) whereby while the installation appeared to complete successfully, I could not communicate with the service to configure it post-installation.

After a little digging, it turned out that the installer had created the firewall rule exemptions for to wrong profile (i.e. public rather than domain). The solution was to run the following PowerShell to update the profile for the PCNS firewall rules to match the network profile the server was operating on:

Get-NetFirewallRule | where {$_.DisplayName -like “PCNS*”} | Set-NetFirewallRule -Profile Domain

Once the firewall rules were updated, communication was restored and configuration could be completed from a browser running on another machine.