Wellington Solution Architects Forum

Wellington Solution Architects Forum - New user group in Wellington kicked off in September. Already they had few interesting sessions.

WSAF

There is also a linkedin group to subscribe - WSAF linkedin group

If you're a user of the Objective document management system, you probably need to configure client computers via various registry hacks.

To make it easier here is a Microsoft Group Policy administrative template for the Objective 7.3 client.

Emptying Windows XP temporary directories the Powershell way.

I previously blogged about emptying the Windows XP temporary directories with a batch file. For completeness, here is how to do the same thing with Powershell.

ri -rec $env:windir\temp\* -force
ri -rec $env:temp\* -force
if ($env:temp -ne $env:tmp)
{ ri -rec $env:temp\* -force }

Quick and dirty server operating system audit.

I was sitting at my desk and I overhead a conversation about the Microsoft Licensing true up. There was a suggestion that someone would have to log into each server to find out what particular flavour of Windows is installed.

Now of course this information should be readily retrievable via WMI from the Win32_OperatingSystem class so I said I'd whip up a quick script that would produce a report.

As I remembered there is a property OperatingSystemSKU which holds this information, but it turns out to be Windows 2008 and beyond. After a bit of mucking around I discovered that the first part of the Name property value had the information I wanted. So it was simply a matter of snipping this out.

The script below uses the Quest Active Directory Cmdlets to query for all server computer objects, uses Win32_PingStatus to determine if the host associated with the object is actually responding, and does a WMI query for the details we want if it is. I decided to grab the O\S Architecture and Service Pack as well.

$now = $now = get-date -uformat "%Y%m%d"
$Domain = [DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$filename = "servers-$domain-$now.txt"
$computers = get-qadcomputer -sizelimit 0 -ldap '(operatingSystem=*server*)' %{$_.dnshostname}
Set-Content $filename "Report on server Operating System information in $domain created $now"
"HostName, SKU, Architecture, Service Pack" Add-Content $filename
ForEach($Computer in $Computers) {
  $Result = Get-WmiObject -Class Win32_PingStatus -Filter "address='$computer'"
  If ($Result.Statuscode -eq 0) {
    If ($computer.length -ge 1) {
      $WMI = GWMI -computer $computer -query "Select * from Win32_OperatingSystem"
      $Name = ($WMI).Name
      $Arch = ($WMI).OSArchitecture
      $SPMaj = ($WMI).ServicePackMajorVersion
      If ($Name -ne $null) {$NiceName = $Name.Substring(0,$Name.IndexOf(''))} Else {$NiceName = ""}
      "$Computer, $NiceName, $Arch, $SPMaj" Add-Content $filename } }
    Else { "$Computer did not respond." Add-Content $filename}}

Restoring your Windows quick launch bar show desktop icon.

If you're like me you use the Windows Quick Launch bar a lot. So when you loose your Show Desktop icon it is really annoying. To restore it you need to create a new file in the Quick Launch directory. But it's also annoying when you have to google for instructions every time. And as I do weird stuff to PCs, every time can be more than once a year, and that means remembering what the file name is, or the name of the little bar thingy at the bottom of the screen, where my little clicky thing with the pencil used to be.

To solve these many problems I have have created myself a small Powershell script to do it for me.

#Create Windows XP Quicklaunch bar Show Desktop icon
#requires Powershell 1.0
$FileName = "$env:appdata\Microsoft\Internet Explorer\Quick Launch\Show Desktop.scf"
New-Item -ItemType file $fileName
Add-Content $FileName "[Shell]"
Add-Content $FileName "Command=2"
Add-Content $FileName "IconFile=explorer.exe,3"
Add-Content $FileName "[Taskbar]"
Add-Content $FileName "Command=ToggleDesktop"

And in case Brandon Shell finds this post, here's the same thing in three lines,so he doesn't taunt me, and call me a $noob. (Make sure if you cut and paste it to correct any line wrapping problems).

$FileName = "$env:appdata\Microsoft\Internet Explorer\Quick Launch\Show Desktop.scf"
$Content="[Shell]`nCommand=2`nIconFile=explorer.exe,3`n[Taskbar]`nCommand=ToggleDesktop"
Set-Content $filename $content

Of course you could collapse that down to one line

Set-Content "$env:appdata\Microsoft\Internet Explorer\Quick Launch\Show Desktop.scf" "[Shell]`nCommand=2`nIconFile=explorer.exe,3`n[Taskbar]`nCommand=ToggleDesktop"

but that's getting pretty silly isn't it.

Active Directory Port Requirements

Recently I was setting up the group policies to control the firewalls in a Windows 2008 Domain. I was asking around trying to find out exactly what ports the Domain Controllers needed open. No one could come up with a definitive list.

Now the Active Directory documentation have come up with the proper documentation. See it at
Active Directory and Active Directory Domain Services Port Requirements.

Windows Server Log Sizes

Microsoft recommends different log sizes for Windows 2003 and Windows 2008 servers based on whether you are running a 64bit or 32 bit operating systems. You can find these recommendations in Article ID 957662. Obviously you don't want any bad things to happen to your servers so you don't want to accidentally apply the 64bit log size recommendations to a 32bit server, so you need a method of making sure each O/S architecture gets the appropriate settings.

The best way of applying a setting to multiple servers is to use Group Policy Objects. The best way of targeting our particular O/S architectures is to use a WMI filter on a GPO. Now the challenge is to work out what WMI class and what property to use.

The obvious candidates are WIN32_OperatingSystem and WIN32_Processor. The next step is testing a few machines to see what property is the one for the job. The easiest way to do this is to use PowerShell and the Get-WMIObject command.

Using this technique it becomes obvious that the OSArchitecture property of WIN32_OperatingSystem is the one we want but it doesn't always get returned. So WIN32_Processor it is then, and AddressWidth is the property. Michael B. Smith has a blog post 32-bit or 64-bit - What Is My Processor? which is informative on the subject.

So we want AddressWidth, but wouldn't it be nice to check all of our servers to make sure. That's easy to do with PowerShell and the Quest AD cmdlets. The following script shows you how.

$OU = "enter you server OU here"
$computers = Get-QADComputer -searchroot $OU | %{$_.dnshostname}
$query = "Select systemname,addresswidth FROM Win32_Processor"
ForEach($Computer in $Computers) {
  $Result = Get-WmiObject -Class Win32_PingStatus -Filter "address='$computer'"
  if($Result.Statuscode -eq 0) {
    if($computer.length -ge 1) {
      Get-WMIObject -query $query -comp $computer | Select-Object systemname,addresswidth | Sort-Object systemname
    }}}

So now we have our WMI filters to determine the scope of our GPO containing log settings the query for 32bit Operating Systems is

"select * from Win32_Processor where AddressWidth = 32"

and for 64bit Operating Systems it is

"select * from Win32_Processor where AddressWidth = 64"