Tag Archives: tfs

Removing dead library servers and hosts from SCVMM

A while back I was setting up TFS Lab management so that we can start automating a lot of our integration testing. In the process of testing the deployment of the servers and the auto configuration scripts I was creating a lot of temporary virtual servers on the domain and using up IP’s on the network before they could be released. Therefore I wasn’t too popular with the OP’s guys and they decided to put the lab server in it’s own domain.

Unfortunately this caused a few issues as it meant that the SCVMM backed could not contact the hosts and the library servers as they had moved domain. Removing the hosts was a simple matter of dropping to PowerShell (There is a handy button at the top of the SCVMM Admin console) and running the following command:

Remove-VMHost "[SERVER_FQDN]" -Force

However the PowerShell command for removing dead library servers is not so helpful as it doesn’t have a “Force” flag and it comes up with an error saying it can’t be contacted:

Error (406) - Access has been denied while contacting the server

Luckily as the SCVMM backend is controlled by Sql server it wasn’t too difficult to find where the definitions of the library server were stored. Just connect to the SCVMM database instance ([YOUR_SCVMM_SERVER]\MICROSOFT$VMM$) and the table you need to look at is the tbl_ADHC_Library table. Firstly do a select on the table to get the GUID/UNIQUEIDENTIFIER of the library server(s) you need to delete:

use VirtualManagerDB
go

select
    LibraryID,
    ComputerName
from dbo.tbl_ADHC_Library

From this query take the LibraryID field and for each of the library servers you need removing, run the following command:

use VirtualManagerDB
go

exec prc_ADHC_Library_Delete '[LibraryID]'

Hey presto all the dead servers are now gone!

As always please make sure you have a backup and don’t blame me if you break your SCVMM server!!

A few “features” in MSBuild that caused me pain today…

Today I decided to work on deploying to both our internal load-balanced app servers directly from a manually run build. Unfortunately I came across the following issues that caused me to spend far too long on this task!!

Currently I have a library of MSBuild .targets files that load in generic tasks that I can run after a build has run. One of them is a DeployWebsite task that uses a couple of Properties and can clean down and deploy the latest code from the build. I realised that all I needed to do was modify the current build to set the deploy location first. However this turned out to be a lot harder than I thought it would be…

Firstly I tried the following code which doesn’t set the Global property “AppFolderPath”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <AppFolderPath>[INVALID]</AppFolderPath>
    </PropertyGroup>
    <Target Name="SetDeployLocation">
        <PropertyGroup>
            <AppFolderPath>[SOME SHARE ON SERVER]</AppFolderPath>
        </PropertyGroup>
        <CallTarget Targets="DeployWebsite" />
    </Target>
    <Target Name="DeployWebsite">
        <Message Text="AppFolderPath=$(AppFolderPath)" />
    </Target>
</Project>

To fix this you need to seperate the tasks into two Targets and call them from a single parent Target and set the Property using CreateProperty (not declaratively and doesn’t matter if you have already created it!):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <AppFolderPath>[INVALID SHARE]</AppFolderPath>
    </PropertyGroup>
    <Target Name="DeployToLive">
        <CallTarget Targets="SetDeployLocation" />
        <CallTarget Targets="DeployWebsite" />
    </Target>
    <Target Name="SetDeployLocation">
        <CreateProperty Value="[SOME SHARE ON SERVER]">
            <Output TaskParameter="Value" PropertyName="AppFolderPath" />
        </CreateProperty>
    </Target>
    <Target Name="DeployWebsite">
        <Message Text="AppFolderPath=$(AppFolderPath)" />
    </Target>
</Project>

Once I’d fixed those it still wouldn’t call the DeployWebsite multiple times. The first worked fine, however it turns out that MSBuild will not allow you to call a target with the same name twice. To get around this you can spawn a separate MSBuild task for each instance you need to run:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="DeployWebsiteToLive">
        <MSBuild Targets="DeployWebsite"
            Properties="AppFolderPath=[SHARE ON SERVER 1];BuildDirectory=$(BuildDirectory)"
            Projects="$(MSBuildProjectFile)" />

        <MSBuild Targets="DeployWebsite"
            Properties="AppFolderPath=[SHARE ON SERVER 2];BuildDirectory=$(BuildDirectory)"
            Projects="$(MSBuildProjectFile)" />
    </Target>
    <Target Name="DeployWebsite">
        <Message Text="AppFolderPath=$(AppFolderPath)" />
    </Target>
</Project>

One thing to notice there is you need to pass across ALL properties that are not set declaratively. If you do not pass anything these are all sent across automatically, but MSBuild still detects that the two tasks are exactly the same and only runs the first one.

Hopefully you won’t have to spend as long as I did on it now! 🙂

Team build fails even though the project builds fine.

The last few days we’ve been having a strange problem where TeamBuild on our TFS server was repeatedly failing. What was even weirder was that the solution definitely builds OK and there are no compile errors. So I started digging around in the log file and as you will no doubt know (On average mine are 3k-10k line plain text files!!) this is a rather painful task.

After quite a while looking through this it was a fruitless exercise and was no closer to find out why. Luckily I have already setup other VM build servers and these were running ok so was able to narrow it down to the TFS server itself. Next I tried deleting the BuildSources folder to see if there was any rouge or corrupt files there. Nope, not that. I vaguely seemed to remember that the Build process itself runs as a windows service so I checked that out. Was seemingly working fine but decided to give it a bounce just incase. AS always this action seems to work and the build server started working fine. I just wish I’d always remember to log-out/restart app/reboot first as this would have saved a LOT of time.

Just remember when 1st-line tell you to log-out/reboot, do it, you might be surprised!! 🙂