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:

Navigate to the “Program Files\Research In Motion\BlackBerry Enterprise Server\BAS\bin” directory

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.

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!).

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

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.