MassFlash v1.0
Preparing many flash disks with the same data is tedious and might I add very boring. On my quest to learn Powershell, I might just as well put it to good use. With just a few lines of code I managed to cook up a script to do the mind-numbing work of preparing flash disks. It does the work and I watch. Perfect!
It is a very simple script that:
- Formats each flash drive to FAT32;
- Copies the contents of the specified directory recursively onto the flash drive;
- Dismounts the volume.
The script finds all removable drives between 1gb and 64gb in size. We don’t want to slip up here, now do we?
At the top of the script, a default directory is specified from where all files will be copied if an alternative directory was not specified on the command line.
Write-Host "MassFlash - Version 1.0"
Write-Host "Author: SS du Plooy"
Write-Host "-----------------------"
If($args.Length -eq 0)
{
$DirectoryToCopy = "c:\DefaultFromCopyLocation"
}
Else
{
$DirectoryToCopy = $args[0]
}
Write-Host "Preparing flash disks with files from" $DirectoryToCopy
$drives = Get-WmiObject Win32_LogicalDisk -filter "DriveType=2"
Foreach($drive in $drives)
{
[int] $driveSize = $drive.Size/1073741824 #convert to gigabytes
If($driveSize -ge 1 -and $driveSize -le 64)
{
$driveLetter = $drive.DeviceID
$volume = Get-WmiObject -Class Win32_Volume -Filter "DriveLetter = '$driveLetter'"
$label = "TKP"+$(get-date -f ssfff)
Write-Host Formatting drive $driveLetter [$label] [$driveSize GB]
$volume.Format("FAT32", $true, 4096, $label, $false)
Write-Host "Copying $DirectoryToCopy to $driveLetter"
Copy-Item $DirectoryToCopy $driveLetter -recurse
Write-Host Dismounting drive $driveLetter
$volume.Dismount($true, $false)
}
}
Write-Host "Done."
Now you can put your time and mind to better use instead of preparing flash drives all day long.
Note: The script must be run with Administrator privileges.
Monitoring disk space with Powershell
Running out of disk space all of a sudden is just not cool. It tends to wake up men in black suits, bring on the gnashing of teeth and frothing at the mouth. I don’t like that type of drama.
So, I knocked up a little Powershell script that can be scheduled to email a disk space report everyday. Currently the script is written to send a report on a single drive only. There are many other variations of this type of script that reports on all the drives on a server.
$disk = Get-WmiObject -ComputerName $env:COMPUTERNAME Win32_LogicalDisk | Where-Object {$_.DriveType -eq 3} | Where-Object {$_.DeviceID -eq ":"}
[float]$totalSize = [Math]::Round($disk.Size / 1073740824, 2)
[float]$freeSpace = [Math]::Round($disk.FreeSpace / 1073740824, 2)
$deviceID = $disk.DeviceID
$percentFree = [Math]::Round(($freeSpace / $totalSize) * 100, 2);
$smtpServer = ""
$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
$emailFrom = "$env:COMPUTERNAME"
$emailTo = ""
$subject = "$env:COMPUTERNAME - Disk space report"
$body = "$deviceID | Total: $totalSize GB | Available: $freeSpace GB | $percentFree % disk space available"
$smtp.Send($EmailFrom,$emailTo,$subject,$body)
When it comes to management, you might just as well only print the precentage of free disk space and perhaps add that to the subject of the email. That will give all the relevant information in one look. The script can be extended to report on multiple servers and multiple drives.
Have fun!
Unit testing with Jenkins
Continuing to setup a build for the first time with Jenkins there is, uh, another challenge. For some reason, I thought it clever to make use of MsTest. This works wonderfully on the development machine. But, of course, when it comes to the build server, you can expect all sorts of weirdness. For example, error CS0246: The type or namespace name ‘TestMethodAttribute’ could not be found…
We’re sorry, but our testing tools don’t come standard with the .NET Framework, or in any other way, except TFS and Visual Studio, unless you are willing to follow this brave soul. I share Derik Whittaker’s sentiment on the MsTest and build server issue.
This is another issue to me because MSTest is the ONLY test framework (for .Net) that I know of that does not run with a single DLL placed into the bin (or any other output directory). I just have to ask the genius’ over in Redmond what the hell were they smoking when they decided to build MSTest. It is pretty clear they had no prior knowledge of how to use the other tools such as NUnit, MBUnit or xUnit (I know, xUnit was not out yet). I know this because of all the various testing frameworks MSTest is the one that does everything different. You could argue they were on the cutting edge and were innovating, but I call BS on that.
This can be solved. So long MsTest… Hello NUnit!
Converting from MsTest to NUnit
Converting from MsTest is a simple case of find and replace of attributes. NUnit has the nifty Assert.Catch<T> which beats MbUnit, MsTest and xUnit. xUnit comes with Assert.Throws<T> but cannot assert the exception message whereas NUnit can. No more [ExpectedException] attributes.
Integrating NUnit with the build file (which is MsBuild) is pretty easy:
<Exec Command=”$(NUnitFolder)\nunit-console-x86.exe [TestAssembly] /framework=net-4.0 /xml=$(TestResultsFolder)\TestResults.xml” />
A single Exec statement and out comes an Xml file. To keep the build server clean, I decided to add all the necessary files for unit testing into source control along with the project. The bare minimum files for running NUnit from the command line comes down to the following files:
- nunit.core.dll
- nunit.core.interfaces.dll
- nunit.framework.dll
- nunit.util.dll
- nunit.console-runner.dll
- nunit-console-x86.exe
- nunit-agent-x86.exe
- nunit-agent-x86.exe.config
To make it work on .Net Framework 4.0, you have to include the /framework=net-4.0 switch on the command line.
Setting up Jenkins with NUnit
Install the NUnit plugin for Jenkins, point it to your test results file and after a build you’ll get the summarised test results. It’s a neat table with all the classes and their respective timings and so on.
Finally, I have a working build with unit testing. If only it had an installer…
Jenkins and Git
The road split for Hudson and Jenkins. It happens.
Getting the source code…
I don’t have Cygwin or MSysGit installed on the server for my own perverse reasons. In order for Jenkins to get hold of the source code from a git repository is usually straight forward. Well, now comes the time to get the source code from git. I can clone repository into a local directory using GitSharp. GitSharp is the .net version of git and very cool, but not quite finished yet. The alternative is a Java application called JGit. GitSharp, by the way, is a derived work of JGit.
Setting up Jenkins…
Download the shell script of JGit which, by the way, is a self-contained command line executable. With that, I am able to test the cloning of a repository into a new folder with the following command line:
C:\JGit>java -cp org.eclipse.jgit.pgm-0.10.1.sh org.eclipse.jgit.pgm.Main clone
http://dev/git/myproject.git c:\projects\myproject
After executing the above command line, I have the source files in the c:\projects\myproject directory. To use this in Jenkins, I need to make use of the batch command execution since the git plugin makes use of git.exe and all the other things I didn't setup.
After running a build, I have the following console output in Jenkins and the source code in the build factory directory:Started by user anonymous [MyProject] $ cmd /c call C:\Windows\TEMP\hudson12048252217381411.bat d:\builds\factory\MyProject>"C:\Program Files\Java\jre6\bin\java.exe" -cp c:\jgit\org.eclipse.jgit.pgm-0.10.1.sh org.eclipse.jgit.pgm.Main clone http://dev/git/myproject.git d:\Builds\Factory\MyProject Initialized empty Git repository in d:\Builds\Factory\MyProject\.git remote: Counting objects: 342, done From {0} * [new branch] master -> origin/master d:\builds\factory\MyProject>exit 0 Finished: SUCCESS
by Sydney du Plooy
Resizing a virtual hard disk
Recently, I had to resize a VHD (virtual hard disk) that I installed Windows Server 2008 on. I soon found out that the size of 10GB is not such a hot idea when installing Team Foundation Server 2010 and SQL Server 2008 on the same instance. Hence, I decided to resize the disk instead of re-installing all of the software.
Below is the recipe to resize the virtual hard disk:
Part 1:
The first part is to resize the container of the partition, which is done by means of a sector copy. After the resize completed, the container will have increased but the partition will not be fully extended yet.
- Download VHD Resizer from VMToolkit.
- Install and run VHD Resizer.
- In the file open dialog select the VHD that you want to resize.
- Type in the new filename to use for the extended VHD.
- Type in the size of the new container to create.
- Click on Resize. The process takes a few minutes…
Part 2:
Now that the container is resized, we must now extend the partition to make use of the full container size.
- Attach the new extended VHD as a non-primary drive to another virtual machine. Do not extend the partition using the virtual machine that will make use of it.
- Start the virtual machine to which the extended VHD was attached as the non-primary drive and open a command prompt.
- Type in diskpart and press Enter.
- Type in list disk.
- Ensure that disk 1 or greater is the extended disk.
- Type in select disk 1.
- Type in list partition.
- Ensure that the partition sizes matches the old size.
- Type in extend.
- Wait for the process to complete and type exit.
Remember to change the disk on the original virtual machine to now use the extended disk. The disk is now resized and ready to be used from the original virtual machine.
AWOL CD-ROM
For the second time now I have had the CD-ROM drive on my HP nw8440 disappear from Windows. The Device Manager reports the following for the CD-ROM drive: “Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)”. Why? It was perfect yesterday and today it is missing or corrupted? Weird. According to the Microsoft Knowledge Base article it can happen after removing a CD or DVD burning program.
Although the error is rather annoying, there is a simple fix for it. I have replicated the steps here for your convenience:
Step 1: Start Registry Editor
Start Registry Editor.
Step 2: Delete the UpperFilters registry entry
- In Registry Editor, expand My Computer, and then expand HKEY_LOCAL_MACHINE.
- Expand SYSTEM, and then expand CurrentControlSet.
- Expand Control, and then expand Class.
- Under Class, click {4D36E965-E325-11CE-BFC1-08002BE10318}.
- In the details pane of Registry Editor, on the right side, click UpperFilters.Note You may also see an UpperFilters.bak registry entry. You do not have to remove that entry. Click UpperFilters only.
- If you see the UpperFilters registry entry in the details pane of Registry Editor, go to step 6.
- If you do not see the UpperFilters registry entry, you still might have to remove the LowerFilters registry entry. To do this, go to “Step 3: Delete the LowerFilters registry entry.”
- On the Edit menu, click Delete.
- Click Yes when you receive the following message:
The UpperFilters registry entry is removed.
Step 3: Delete the LowerFilters registry entry
- In the details pane of Registry Editor, on the right side, click LowerFilters.Note You might see a LowerFilters.bak registry entry. You do not have to remove that entry. Click LowerFilters only.
If you do not see the LowerFilters registry entry, unfortunately this content is unable to help you any more. Go to the “Next Steps” section for information about how you can find more solutions or more help on the Microsoft Web site.
- On the Edit menu, click Delete.
- Click Yes when you receive the following message:
The LowerFilters registry entry is removed.
- Exit Registry Editor.
The article recomends restarting the computer after deleting the two registry entries, but I have found that it works fine without restarting.
Rebuilding the COM+ Catalog
After my post on rebuilding the WMI Repository, I thought it might be a good thing to write a post on rebuilding the COM+ Catalog. It is unlikely that you’ll ever have to rebuild a corrupt COM+ Catalog, but it certainly is possible, for example when you get errors such as “Catalog Error 8008005 – Server Execution failed”.
This article by Microsoft describes the process to follow when rebuilding the COM+ Catalog. I’ve duplicated the steps here for ease of reference:
- Rename the %WinDir%\System32\Clbcatq.dll file to %WinDir%\System32\~Clbcatq.dll. Make sure that you include the tilde (~) at the start of the file name.
- Restart the computer.
- Start Registry Editor (Regedt32.exe).
- Locate and delete the following key in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3
- At a command prompt, type cd %windir%, and then press ENTER.
- At a command prompt, type rmdir /s Registration, and then press ENTER. This is the location folder of the registration database. Note: If you have MS04-012 installed, you must now re-install MS04-012. For more information about security update MS04-012, click the following article number to view the article in the Microsoft Knowledge Base: 828741
- Click the Start button, point to Settings, and then click Control Panel.
- Double-click Add/Remove Programs, and then click Add/Remove Windows Components.
- Click Next to go through the reinstallation process, to reinstall COM+.
- If IIS is installed on the computer, IIS creates several COM+ applications. These applications will now be missing. To re-create these applications, run the following command at a command prompt: rundll32 %windir%\system32\inetsrv\wamreg.dll, CreateIISPackage
Rebuilding WMI Repository
After having a bit of a struggle with Service Pack 1 for Team Foundation Server 2008, I had to restore a previous installation of Team Foundation Server 2005. After restoring the server, which runs on Virtual Server 2005 R2 everything seemed fine. It was only when trying to upgrade Team Foundation Server 2005 to 2008 that I received an error complaining about the WMI provider for SQL Server 2005.
Trying to look into this issue, I opened the SQL Server Configuration Manager and then received the following error:
“Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 servers with SQL Server Configuration Manager.
Initialization failure [0x80041014]“
This is not pretty. I went to Google the issue and discovered this post. It seems like the WMI repository corrupted when I did the restore. Nice. So, I followed the instructions detailed in the post, but no luck. It still returned with the same error that I received in the beginning.
The WMI Repository was corrupt in its entirety. How do you rebuild the WMI Repository? Not so easy it seems. Lukcily there is post describing the whole process with a neat little batch file that will rebuild the WMI Repository for you, came in very handy.
Note: Execute the following commands from this directory: C:\Program Files\Microsoft SQL Server\90\Shared
Here is the batch file duplicated for convenience:
net stop winmgmt c: cd %systemroot%\system32\wbem rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof mofcomp cimwin32.mfl mofcomp rsop.mof mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
echo DONE pause
mofcomp sqlmgmproviderxpsp2up.mof
After performing the above steps, I rebooted the server and Team Foundation Server upgraded successfully.
by Sydney du Plooy
leave a comment