The aggregate of the blogs of Black Marble Staff
Whilst I was off work last week TFS 2018 Update 3 was released. As stated in the 2018.3 release notes this is the final bug fix update release of TFS 2018.
The next major release of TFS will not be named TFS 2019 as you might have expected, but will use the new name of Azure DevOps Server. You can see the features planned for this next release in the Azure DevOps Features Timeline
The Azure DevOps (VSTS) team have published the promised postmortem on the outage on the 4th of September.
It gives good detail on what actually happened to the South Central Azure Datacenter and how it effected VSTS (as it was then called).
More interestingly it provides a discussion of mitigations they plan to put in place to stop a single datacentre failure having such a serious effect in the future.
Great openness as always from the team
Today Microsoft made a big announcement, VSTS is now Azure DevOps.
The big change is they have split VSTS into 5 services you can use together or independently, including Azure Pipelines for CI/CD – free for open source and available in the GitHub CI marketplace.
An important thing to note is that IT IS NOT JUST FOR AZURE.
Don’t be afraid of the name. There a wide range of connectors to other cloud providers such as AWS and Google Cloud, as will as many other DevOps tools
The documentation for the VSTS WIKI suggests you can embed a video in a VSTS WIKI using the markdown/HTML
<video src="_media/vstswiki_mid.mp4" width=400 controls> </video>
Problem is that this does not seem to work, the MP4 just does not appear, you get an empty video player.
However, if you swap to a full URL it does work e.g.
<video src="https://sec.ch9.ms/ch9/7247/7c8ddc1a-348b-4ba9-ab61-51fded6e7247/vstswiki_high.mp4" width=400 controls> </video>
This is a problem if you wish to store media locally in your WIKI
The workaround is to either place the MP4 file in some URL accessible location e.g. some Azure web space (not really addressing the problem), or more usefully use the VSTS API to get the file out the repo that backs the WIKI.
The format of the HTML tag becomes
<video src="https://vstsinstance.visualstudio.com/MyTeamProject/_apis/git/repositories/MyTeamProject.wiki/Items?path=_media%2Fvstswiki_high.mp4 width=400" controls> </video>
This will get the current version of the file on default branch, you can add extra parameters to to specify versions and branches if required as per the API documentation.
So not a perfect solution as you have to think about branches and versions, they are not handled automatically, but at least it does work
A pull request for Chris Gardner’s WebApplicationProxyDSC is now inbound after a frustrating week of trying to automate the configuration of ADFS and WAP on a Server 2016 lab.
With Server 2016, the PowerShell commands to configure the ADFS and WAP servers include switches to specify a non-default port. I need to do this because the servers are behind a NetNat on a server hosting several labs, so port 443 is not available to me and I must use a different port.
This should be simple: Specify the SSLPort switch on the Install-ADFSFarm command and the HttpsPort on the Install-WebApplicationProxy command. However, when I do that, the WAP configuration fails with an error that it cannot read the FederationMetadata from the proxy.
I tried all manner of things to diagnose why this was failing and in the end, the fix is a crazy hack that should not work!
The proxy installation, despite accepting the custom port parameter, does not build the URLs correctly for the ADFS service, so is still trying to call port 443. You can set these URLs on a configured WAP service using the Set-WebApplicationProxyConfiguration command. However, when you run this command with no configured proxy, it fails.
Or so you think…
On the ADFS Server:
On the WAP Server:
Despite the fact that step 2 says it failed, it seems to set enough information for step 3 to succeed. My experience, however, is that only doing steps 2 and 3 does not work. Weird!
As a side note, testing this lot is a lot easier if you remember that the idpinitiatedsignon.aspx page we all normally use for testing ADFS is disabled by default in Server 2016. Turn it on with Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
When you want to register a build agent with VSTS, you use the VSTS instance’s URL and a user’s Personal Access Token (PAT). Whilst doing this today I connected to the VSTS instance OK but got the error “Agent pool not found”.when I was asked to pick the agent pool to add the new agent to.
As the user who’s PAT I was using was a Build Administrator I was a bit confused, but then I remembered to check their user access level. It was set to Stakeholder, once this was changed to Basic I was able to register the agent without use.
Also, so as to not use up a Basic license, when I did not need to, I swapped the user back to being a Stakeholder once the agent was registered. This can be done as the token used for the actual build is not the one used to register it, but one assigned at build time by VSTS.
You have always been able to customise your Team Projects in TFS, by editing a host of XML files, but it was not a pleasant experience. In VSTS a far more pleasant to use web based inherited customisation model was added, much to, I think, most administrators relief.
If you used the TFS DB migration service you ended up with a VSTS instance full of the the XML style team projects, and you were stuck there, with no way to change these to the new inherited mode, that is until now as Microsoft have released to preview a conversion tool.
I have been trying this tool to migrate all our active XML based team projects to Inherited equivalents, and it has worked very well for me, but I have to say, we don’t have any hugely complex customisations, so your mileage may vary depending on how much you modified your XML based team project templates.
However, I wanted to go further than the basic process as documented
Since moving to VSTS all our new team project have been created using an inherited template based on Scrum. I wanted to move all our active XML based team project to this standardised template. This took a little extra work.
The basic process is easy as to change Inherited Process you
REMEMBER: A really nice touch (with XML and Inherited templates) is that you can just switch back if you don’t like the result, no data is lost when you swap templates, but some of it might be hidden as fields are not shown on the new work item types.
The problem I had was that our old XML based team project templates had different customisation to our current inherited standard. To address this I needed to
So once done, I was then able to migrate all the team project to my target process template.
So a very nice experience, and one that now means we can make sure all our team projects use the same set of customisation. No longer do we need to worry about customising in XML and Inherited models.
I have just rebuilt my first generation Surface Book from our company standard Windows image. These images are used by all our staff all the time without issue (on Surface and Lenovo devices), so I was not expecting any problems.
I used to rebuild my PC every 6 months or so, but got out the habit when I moved to a model I could not swap the hard drive out of as backup during the process (using a new disk for new install). I got around this by using Disk2VHD, not quite as good as I can’t just swap the disk back in, but I won’t have lost any stray files, even though I always aim to keep data in OneDrive, Source Control or SharePoint, so it should not been an issue anyway.
Anyway, the rebuild went fine, no issues until I tried to enable Hello to login using the camera. The process seemed to start OK, the wizard ran, but after a reboot there was no Hello login option.
After a bit of digging I found that in device manager there were no imaging devices at all – strange as the Camera App and Skype worked OK.
The Internet proved little help, suggesting the usual set of ‘you have a virus install our tool’ but after much more digging around I found that the cameras were all under ‘System Devices’ in device manager. So I then…
That was all much more complex than hoped for. My guess is that the system rebuild changed some firmware in a strange way that makes for the misdetection of the cameras.
Anyway it is working now.
A colleague recently started seeing an issue when attempting to add their work account to a Windows 10 device. Following a device re-image (this, as we’ll see becomes important…), a colleague saw the following error reported when attempting to add their work account:
The full text of the error reads
We can’t add this account. Your organisation’s IT department has a policy that prevents us from adding this work or school account to Windows.
Initially we looked at whether recent policy changes had in fact impacted the ability to add a work account to a Windows 10 device, but were not seeing anything that appeared to impact this. We had other users who were receiving new PCs that were unaffected and had the same policies applied to them. In addition, nothing was showing up in the event viewer folder for Workplace Join on their machine when attempting to add the account.
Realising that the machine had just been reimaged, we checked in Azure AD to view the list of devices. The following is a screen shot for a different device ID, however this was similar to what we saw:
As can be seen, there are multiple instances of the ‘same’ machine. In each case, the machine has been reimaged and then had the work account added. In each case, Azure AD has obviously assigned a new device ID, hence what appears to be multiple copies of the same machine registered.
Once we’d deleted a few of the ‘old’ machines from the list, the user was able to successfully add their work account to the device.
There are a couple of potential solutions in our scenario:
Updated 3 July 2018 – A colleague, Andy Davidson, suggested mRemoteNG as an alternative tool to this address this issue. mRemoteNG also has the advantage that it support most major remoting technologies not just RDP, so I am giving that a try for a while.
This is one of those post I do mostly for myself so I don’t forget how I did something, it is all based on answers on SuperUser.Com, I can claim no credit
I have a SurfaceBook (first generation) and when I am in the office it is linked to an external monitor, with a different lower DPI, via a dock. If I use Remote Desktop (MSTSC) as built into Windows 10, I can drag sessions between the two monitors and the DPI shift is handled OK. However, if I use my preferred tool Remote Desktop Manager 2.7 (as it allow me to store all my commonly used RDP settings) I am in DPI hell. I either get huge fonts or microscopic ones. This is bad whether working on the single high DPI laptop screen work with an external screen.
As the SuperUser.Com post states the answer is to change the compatibility settings for the manager by right clicking on the file “C:Program Files (x86)MicrosoftRemote Desktop Connection ManagerRDCMan.exe”, selecting compatibility, change high DPI settings, and unchecking high DPI setting override
Once this was done, I have readable resolutions on all screens.
Why did I not do a better search months ago?