Steve Spencer's Blog

I’m using Release Manager in Visual Studio Team Services (i.e. the one in the cloud) to deploy to my On Premises backend servers. Release Manager does this by using an agent in the environment within which you want to deploy. You can deploy and configure the agent through Release Manager and instructions are at https://blogs.msdn.microsoft.com/visualstudioalm/2016/04/05/deploy-artifacts-from-onprem-tfs-server-with-release-management-service/

However this requires remote PowerShell configuring on the target machine to work correctly. This you may think is really easy to do.

Run PowerShell as admin then type

Winrm quickconfig

Once configured I had to allow the machine with the agent on to access the target machine

Set-Item wsman:localhost\client\trustedhosts *.<domain name>

And also set up to allow for remote scripts using:

Set-ExecutionPolicy RemoteSigned

Testing this I used:

Enter-PSSession <SERVER NAME>

On all my local VMs this worked fine but as soon as I tried it on my UAT and Production servers I got a generic error which listed a lot of possible problems:

Connecting to remote server <SERVER NAME> failed with the following error message: WinRM cannot process the request.

The following error with errorcode 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred.

Possible causes are:

-The user name or password specified are invalid.

-Kerberos is used when no authentication method and no user name are specified.

-Kerberos accepts domain user names, but not local user names.

-The Service Principal Name (SPN) for the remote computer name and port does not exist.

-The client and remote computers are in different domains and there is no trust between the two domains.

After checking for the above issues, try the following:

-Check the Event Viewer for events related to authentication.

-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.

Note that computers in the TrustedHosts list might not be authenticated.

-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

Searching for the error returned a lot of similar results including:

Deleting SPNs

https://social.technet.microsoft.com/Forums/windows/en-US/a4c5c787-ea65-4150-8d16-2a19c569a589/enterpssession-winrm-cannot-process-the-request-kerberos-authentication-error-0x80090322?forum=winserverpowershell

A conflict between ports

http://sharepoint-community.net/profiles/blogs/powershell-remoting-error

Sites to help with troubleshooting

https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windows-remote-management-troubleshooting/

None of them fixed the problem. I managed to get Remote Powershell to work by setting the SPN to specific ports but this then broke Reporting Services so I reverted my changes.

You know you are struggling when all the searches you do yield results you have already read, but in one web site that didn’t appear to be relevant I found this little nugget of information

“Remote PowerShell requires port 80 to be available on the Default Web Site”

https://blogs.technet.microsoft.com/exchange/2010/02/04/troubleshooting-exchange-2010-management-tools-startup-issues/

Looking at my web server there was no default website and nothing using port 80 so I added one and remote PowerShell started to work!

I can now deploy from the cloud on to my back end servers without opening any firewall portsJ

TFS Release Manager and Octopus Deploy, both support the concept of approval steps, but why do you need both pre-release and post-release approval steps. When I first started to look at the automated release tools such as TFS release manager I could understand the reason behind the pre-release approval. This step is your quality gate and adds some controls into your process. When creating your release pipeline you will setup a number of environments (e.g. Test, UAT, Pre production, Production) and at each stage you can make a different set of people responsible for allowing the deployment onto each environment.

When the developers have finished their new piece of code and it has been tested in their own environments, they will want to get it onto the servers so that the testers can test it in a more formal way. Currently this may involve the developer talking to the testers and the developers hanging around whilst the testers finish what they are doing so that they can free up the servers ready for the deploy. The developers will then deploy the software to the test environment, hopefully using some method of automation. With release manager, the developers can kick of an automated build and when it is completed it can then automatically create a release ready for deployment. This release can be configured to automatically deploy to the target environment.

The developer can force the software on to the test environment without the tester being ready. The testers for example may be finishing off testing a previous release and need some time before they are ready to accept the software. They may also have a set of criteria that need to be met before they will accept the software onto their environment.

Adding a pre-release approval step that allows the test team to “Accept” the release gives control to the test team and allows them to accept and indeed reject a release. This “Pause” the process allows the testers to check that all the developer quality gates have been met and therefore allow them push back to the developers if they are not happy. As the deployments can be automated, the testers can use the approval process to also control when the new software is to be deployed into their environment, allowing them to complete their current set of tests first. It also frees up the developer, so that they are not hanging around waiting to deploy. Similarly, moving on to UAT, Pre-Prod or Production, a pre-release approval step can be configured with different approvers who then become the gate keepers for each environment.

A pre-release approval step makes a lot of sense and provides order and control to a process and remove a lot of user error from the process.

So what about a post-release approval step, why would you need one? It wasn’t until I started to use TFS Release manager to automatically deploy my applications to Azure Websites where the need to have pre-release approval process became clear. Once I had released my software onto the test environment, I needed a mechanism to allow the testers to be able to reject a release if it failed testing for whatever reason. The post release approval step allowed them to have this power. By adding both a pre and post release approval step for each environment allowed the environment owner to accept the release into the environment when they are ready for it and when they are satisfied that the developers have done their jobs correctly. They can also control when it is ready to move to the next stage in the process. If after completing testing the software is ready to release to UAT then the tester can approve the release which pushes it to the next environment. If the tester is not happy with the release then they can reject it and the release does not move forwards. The tester can comment on the reason for rejection and the release will show red for failure on the dash board. Adding pre and post approval steps to each environment moves the control of software releases onto each environment to a group of people who are responsible for what happens on each.

Using these approval steps can also act as a sanity check to ensure that software releases do not accidentally get pushed onto an environment if someone kicks of the wrong build for example.

I’ve created a release pipeline for my applications which use pre and post approval steps for releases to Test and UAT, I don’t’ have a pre-production environment, but production utilises the staging slots feature of Azure Websites to allow me to deploy the release to staging prior to actually going live. The production environment only has a pre-release approval step, but as it is only going to staging, there is an additional safe guard to allow the coordinated live release when the business is ready.

Both Pre and Post release approval steps provide a useful feature to put the control of the release with the teams that are responsible for each environment. The outcome of each approval process can be visible, which also highlights if and when there are issues with the quality of the software being released.

After setting up my Surface Pro with Windows 10 and IoT core I decided that in order to demo it all I needed a Windows 10 VM with it all on. I had a couple of issues that I didn’t get on my Surface Pro.

The first issue I had was that the Windows IoT core watcher application would not run properly and kept shutting down. This is a known bug and has a work around:

Launch the "Developer Command Prompt for VS2015" as Administrator
change the working directory over to "C:\Program Files (x86)\Microsoft IoT"
sn -Vr WindowsIoTCoreWatcher.exe
corflags WindowsIoTCoreWatcher.exe /32BIT+ /FORCE

The second issue was Visual Studio couldn’t connect to TFS online. When I tried to manage connections I got the following error:

SplitterDistance must be between Panel1MinSize and Width - Panel2MinSize.

This seems to happen on both VS 2015 Enterprise RC and Community RC editions. I found a work around as follows:

Open up Team Foundation Server online at <youraccount>.visualstudio.com. Click code, then navigate to the project you want to open, click on the solution file which then opens the solution in the web editor. Click the visual studio icon and VS opens with the team project now in team explorer. Close VS and open it again and your team project should still be  connected to team explorer

Now with Visual Studio working I needed to set Windows into developer mode. This can be done as follows:

Start->settings->Update & Security -> For Developers. However, when I tried this the setting page kept closing. You can also use the Group Policy editor (Gpedit.msc) as follows:

https://msdn.microsoft.com/en-us/library/windows/apps/dn706236.aspx

This is a follow on post from my introduction to Windows Azure Websites and shows you how you can synchronise your website in TFS with Windows Azure.

One of the biggest problems with the way you deploy applications to  Windows Azure is that minor changes (e.g .markup, content and styling) require a redeploy to publish the changes. Windows Azure Websites solves this problem by allowing you to synchronise your website with Team Foundation Server or GIT.

In this post I will show you how easy it is to manage your websites in version controlled environment using Team Foundation Service. Team Foundation Service is a cloud hosted version of Team Foundation Server.

This works by creating a continuous integration build with your source code that will automatically deploy your website after successful build each time code is checked in.

This is configured as follows:

Click the “+” button at the bottom of your portal screen and select Website –> Quick Create

Enter the url details and click Create Web Site

An Empty site has now been created.

This site now needs to be link to your Team Foundation Service. Click on the website in the dash board and then select “Setup TFS Publishing”. you will also note that you can use a GIT repository as well as TFS.

Enter your TFS url (or create a new one), then click Authorize Now.

this connects through to your TFS service and setup the CI build that will deploy your application to the cloud.

The TFS site will now be displayed asking you to authorize the connection

You now need to pick the website you want to deploy. If you haven’t create a site yet then you need to go to ~Visual Studio, create your site and check it in to TFS.

You have now linked your web site in TFS to the Azure Website. This will take a few moments to synchronise.

Your website has not been deployed yet. You need to make a change and then check the changes in

upon check-in the build is started

When the build is complete the new website is deployed

You can also revert back to older versions of the web site by clicking the desired version and then clicking redeploy:

This will start the redeploy of the older version:

A new build is kicked off using the same changeset details as the original deployment. Once the build is complete the  web site is reverted back. this whole cycle only took a few minutes so it is a lot faster than the redeploy mechanism you had previously.

TFS and Windows Azure provide a good mechanism for version controlling your website. Adding application life cycle management to any software development activity is a good thing.

Just finished at the Hacking Imagination event in County Durham. My role was to help mentor and encourage the students from Universities and Colleges in the North East of England to help them to develop their ideas for their Imagine Cup entries.

The event was held in a secret location in county Durham and the students were bussed in.

A number of us from Black Marble attended and performed workshops in Migrating to Azure (me), ALM/TFS (Richard), WPF, SilverLight, Phone 7 101 (Leon), Planning Poker (Me, Leon) & Software War Stories/How to Run a Software Business(Robert, Me). The students were all enthusiastic and asked a lot of sensible questions. The students were put into teams if they hadn’t already formed them, which was interesting to watch as an outsider as it was a bit like a recruitment fair with students walking around from team to team where both sides were deciding whether the person or the team were a good fit. This seemed to have worked well with everyone having a team. the age and skill levels range from college students doing their A levels to MSc.

The aim of the two days was to get the teams in a position where they had an idea that is more than just a software app with a good justification for it. This was a difficult task for a lot of teams as they either had a technology solution and tried to find a problem to solve or a really wide problem that they were trying to solve. Most of the discussions were around getting the teams to think about the whole solution including who it is aimed at and how they are going to deliver it rather than just the software side of the solution. It was also about getting some of the teams to focus down on to a specific area rather than being general. Some of the ideas changed each time I spoke to the teams!!

The (long) 2 days ended with each of the teams doing a presentation of their ideas to the whole group. The whole 2 days was enjoyable and the students seemed to gain a lot from the experiences, bringing some out of their shells.

The thing that impressed me most was the amount of young talent that is around and the abilities they have. One group of students were from a 6th form college doing their A Levels/BTEC and the college had around 15 – 20 attendees, all working hard to deliver a good thought through ideas and presenting their ideas to a group of about 50 people. That is something I used to avoid as much as possible when I was at that age. It is this talent that is the future of IT. Credit must go to the teacher/lecturer who has encouraged this amount of A Level/BTEC students to attend an event like this. Its not an easy task to get teenagers to do anything (he says from experience).

Events like the Imagine cup helps these guys (and girls) to gain real world experience and advice from experts in the field. Getting a chance to influence and help this talent has been rewarding for me and I want to try to help some of these young people more. So thanks to all the people who organised and mentored the event and thanks to the students that attended.

There was a lot of information being passed around and to finish off this post, I’ve put together a list of some of the areas that we were talking about in my sessions. I hope they are useful.

Video of wiring the Windows Azure Access Control service into an ASP.NET website. My bit is at the end and its a no code demo to allow users to login to you website using Live, Google or Yahoo accounts.

The Windows Azure Platform training Kit

The Windows Identity training Kit

Windows Azure Pricing& MSDN subscription allowances

Team Foundation Server in the Cloud

Books

Don't Make Me Think!: A Common Sense Approach to Web Usability : Steve Krug (ISBN: 0321344758)

The Art of Unit Testing – Roy Oshrove

I suddenly started to get a CommunicationObjectFaultedException after I checked my azure code in to TFS

I could get it working by editing the web.config file manually, but it didn’t seem to matter what I actually changed!! It was the act of editing the web.config file that made it writable and it could therefore be written to by the development fabric. When comparing the files it looks like the machine key section is changed. Further investigation pointed me in the direction of the changes made in the Azure SDK 1.3 to support full IIS. During deployment “automatic configuration [of the machine key] occurs at the site-level, overriding any user-supplied value”. When the file is read-only the error occurs. Making the file writable fixes the problem.

The following links explain:

http://blogs.msdn.com/b/windowsazure/archive/2010/12/08/specifying-machine-keys-with-windows-azure-sdk-1-3.aspx

http://msdn.microsoft.com/en-us/library/gg494981.aspx

10 March 2011 : Update – Issue now fixed in Azure SDK 1.4. See Azure SDK 1.4 Released