Shockwave’s Blog

We have been making the move from Microsoft ActiveSync to Blackberry Enterprise Server over the past few weeks and months, today was the first real handset rollout and it didn’t get off to the best start. The first handset to be connected failed and when my messaging administrator went to review the BES configuration he could not login using the web console.

After some poking about we found that the issue was down to a ‘known issue’ which BlackBerry have published here.

The message being presented was: “The username, password, or domain is not correct. Please correct the entry.”” wheather we used Active Directory authentication or the local account. The reason being that the LDAP password is hashed before being stored in the BlackBerry Configuration Database, however, in our instance, this had been stored in plain text, therefore, when the BAS was passing the password hashed, the two did not match. BlackBerry claim this occurs when the password is edited on the BlackBerry Server Configuration screen, however, we found this changed randomly.

Currently there is no known fix but the workaround is to do the following:

1. Navigate to the “Program Files\Research In Motion\BlackBerry Enterprise Server\BAS\bin” directory
2. Run the following command “basUtility “C:\Program Files\Java\jre1.5.0_15” “C:\Program Files\Research In Motion\BlackBerry Enterprise Server\BAS” encode “<LDAP Password>” > C:\<Anything>.txt
3. Open the txt file you’ve created and copy the password which should be in a hashed format.
4. Open SQL and backup the ‘BlackBerry Configuration’ database
5. Now check the password in BASAuthenticationCredentials row of the ‘BlackBerry Configuration’ database and you should see that it is stored in plain text.
6. Replace the plain text password with the hashed one you exported from BES in step 2.
7. Restart the BAS services.

Once done you should now be able to login.

Okay, so as you know we have deployed WSUS 3.0 SP1 in our environment to manage the Server patching. Once we made the group policy change to point all clients at the newly deployed WSUS server we found that when some clients were being added to the console, it was deleting an existing server entry.

After some investigation, we found an article by Stephen Farrar (http://sf.net.nz/node/143) which explains that the Syspep process we had followed to provision our virtual servers did not strip out the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\

CurrentVersion\WindowsUpdate\SusClientId

 This caused the machines with matching ‘SusClientId’ values to overwrite the existing servers. To rectify the issue, one of the Server Technicians in my team developed a script to remove the value and then force the client to re-register with WSUS, this was then deployed via SMS to each virtual server.

The script in question was

Option ExplicitDim strRegKey, WshShell, strServiceName
Set WshShell = WScript.CreateObject(“WScript.Shell”)‘Delete Automatic Update Client IDstrRegKey = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\” _
& “CurrentVersion\WindowsUpdate\SusClientId”
WshShell.RegDelete strRegKeystrServiceName = “wuauserv”
WshShell.Run “Net Stop ” & strServiceName, 0, True
WshShell.Run “Net Start ” & strServiceName, 0, True

 ‘Restart Automatic Update Windows Service

 ‘Force the Client to report to the WSUS Server
WshShell.Run “wuauclt.exe /detectnow /resetauthorization”

The Server Tech that developed the script has his own blog which you can find at http://serverchronicle.blogspot.com he has a multitiude of other useful solutions over there.

Well, there have been a few issues in work over the past few days… We’ve had a consultant in modifying the SCW on most of our servers, this has gone well on the whole, however, following the modification of the Domain Controllers (outside of working hours, naturally!). Following this change, it was apparent that we could no longer remote manage DHCP, this appeared to be a specific option that had not been selected.

Unfortunately, our consultant decided to make this change to allow remote administration to all Domain Controllers through the day, once the change was made everything failed… And by everything, I mean EVERYTHING! Mail, Citrix, SQL, Terminal Services, SMS, SCOM, the list goes on.

Once the policy was removed, services were restored. Not an enjoyable 20 minutes!  But the question is, why did this occur? The only change made was to DHCP remote administration. The only indication to the issue was IPSEC kicking in on the DCs once the policy was applied. More investigation required I think!

After some interesting issues at work, we have been concentrating on the patch management of the server infrastructure. Whilst we do use SMS 2003, I found that it just wasn’t performing as a useful tool to patch the servers, the ITMU just doesn’t do it for me! I am aware that this has improved vastly since the move to SCCM, however, the work that we have completed with BDD in SMS has been extensive and I’m not ready to migrate this.

Since SMS wasn’t making the grade, I looked at moving to WSUS… Now I hadn’t used WSUS since version 2 so I was a little sceptical until I installed it at home and had a play. The new interface is excellent, actually being available through and MMC rather than having to use a web browser and the use of SSRS make the reports very pretty and more importantly, useful.

So WSUS 3 has it all sewn up? Not quite. given that I look after an enterprise infrastructure with almost 300 servers, I could not have the servers restarting as WSUS saw fit. Looking through the group policy options available to support Windows updates I did notice the ‘No auto-restart for for scheduled Automatic Update installation options’ which doesn’t exactly do what it says on the tin, this only applies if a user is logged on at the time of the installation. As this wasn’t ideal we looked at alternatives and found an excellent script squirreled away on technet which downloads and installs approved updates from your WSUS server without the need for a restart (obviously the update isn’t effective until the server is restarted but it is nice to have the choice of when this takes place!).

The script looks something like this:

Set updateSession = CreateObject(“Microsoft.Update.Session”)
Set updateSearcher = updateSession.CreateupdateSearcher()

WScript.Echo “Searching for updates…” & vbCRLF

Set searchResult = updateSearcher.Search(“IsInstalled=0 and Type=’Software'”)
WScript.Echo “List of applicable items on the machine:”

For I = 0 To searchResult.Updates.Count-1
    Set update = searchResult.Updates.Item(I)
    WScript.Echo I + 1 & “> ” & update.Title
Next

If searchResult.Updates.Count = 0 Then
 WScript.Echo “There are no applicable updates.”
 WScript.Quit
End If

WScript.Echo vbCRLF & “Creating collection of updates to download:”

Set updatesToDownload = CreateObject(“Microsoft.Update.UpdateColl”)

For I = 0 to searchResult.Updates.Count-1
    Set update = searchResult.Updates.Item(I)
    WScript.Echo I + 1 & “> adding: ” & update.Title
    updatesToDownload.Add(update)
Next

WScript.Echo vbCRLF & “Downloading updates…”

Set downloader = updateSession.CreateUpdateDownloader()
downloader.Updates = updatesToDownload
downloader.Download()

WScript.Echo  vbCRLF & “List of downloaded updates:”

For I = 0 To searchResult.Updates.Count-1
    Set update = searchResult.Updates.Item(I)
    If update.IsDownloaded Then
       WScript.Echo I + 1 & “> ” & update.Title
    End If
Next

Set updatesToInstall = CreateObject(“Microsoft.Update.UpdateColl”)

WScript.Echo  vbCRLF & “Creating collection of downloaded updates to install:”

For I = 0 To searchResult.Updates.Count-1
    set update = searchResult.Updates.Item(I)
    If update.IsDownloaded = true Then
       WScript.Echo I + 1 & “> adding:  ” & update.Title
       updatesToInstall.Add(update) 
    End If
Next

WScript.Echo  vbCRLF & “Would you like to install updates now? (Y/N)”
strInput = WScript.StdIn.Readline
WScript.Echo

If (strInput = “N” or strInput = “n”) Then
 WScript.Quit
ElseIf (strInput = “Y” or strInput = “y”) Then
 WScript.Echo “Installing updates…”
 Set installer = updateSession.CreateUpdateInstaller()
 installer.Updates = updatesToInstall
 Set installationResult = installer.Install()
 
 ‘Output results of install
 WScript.Echo “Installation Result: ” & installationResult.ResultCode
 WScript.Echo “Reboot Required: ” & installationResult.RebootRequired & vbCRLF
 WScript.Echo “Listing of updates installed ” & “and individual installation results:”
 
 For I = 0 to updatesToInstall.Count – 1
  WScript.Echo I + 1 & “> ” & updatesToInstall.Item(i).Title & “: ” & installationResult.GetUpdateResult(i).ResultCode   
 Next
End If

With this script implemented as a scheduled task on each of my servers and the WSUS server used to approve updates in a phased approach this should form a comprehensive approach to patching with my infrastructure… We should be implementing this soon, we will see how well it goes.

P.S. For those eagle eyed members out there, we will be removing the user interaction from the script before we go live.