BESUserAdminClient.exe find issues

For our Hosted Exchange 2007 environment, we offer a BlackBerry Enterprise Server that allows users to connect their crackberries and have the full functionality that one expects with these devices.

Various automation scripts have been put in place that make it easy for the user to see who has BlackBerry enabled for their account, add additional users and so on. Today, we discovered a rather annoying feature that exposed a bug in our code. Not a horrible bug, but one that did affect the user and their experience with the customer portal.

Here is the basics of the bug. We use the BESUserAdminClient.exe program with the find option to find users. We then search the results for something along the lines of “( 1 results found.” Unfortunately, we were getting false positives on our searches. does not exist on our BES system. However, does. So if you search for, what you are really search for is ** I can’t say the last wild card is there, but the first definitely is.

What we found was that in order to improve our search, we needed to add a -v flag to the search string. That returned our “( 1 results found.” as before. But this time we found the results also returns a CSV result that had a whole bunch of information such as: “User name,MailBoxDN,ServerDN,PIN,Device Type,State,Message Server,Forwarded,Sent,Pending,Filtered,Expired,….” This also exposed that the result that we were getting was actually!

The solution was to now search the verbose (-v) results for and we would now get the desired result back. We would no longer find when we really wanted to see if exists.

I can’t really call this a bug per se. But I consider it an over site in the documentation of the function. It would be nice if there was a flag that I could pass it that would force it to only search for and NOT **

Twitter Issues

Has anyone else been having a bunch of issues with Twitter as of late? It seems like the service is even more unstable than is has been in the past few months.

My biggest complaint right now, besides it being down a lot, is the profile settings. Yes, I’m _finally_ getting around to setting a profile picture for my @usrlocal account.

Here is what I get when I attempt to upload my image:

Good so far! But then when I got to hit save the final time I get the following:

Uh..NO! My picture of 4KB which is 48×48 is NOT to big!

Here’s the really frustrating part, some people are seeing my new image though I get the error message saying that it didn’t update properly.

WTF Twitter?!?!

Zune Glitch

Having dealt with my fair share of timezone issues while programming, I find leap year issues really funny. Thank you Microsoft for starting off my year with a laugh.

Many Zune owners successfully revived their failed music players Thursday morning, while others were still unable to overcome a leap year-related glitch that caused thousands of the devices to simultaneously stop working on New Year’s Eve.

“Mine is back up and working as of a minute ago! Thanks Zune Team,” a user named “blcknwhte” posted at 9:19 a.m. ET on the Zune Web site’s forum.

“I’m glad things are back to normal but this was a major inconvenience,” posted someone named JaximFlash. “I have 2 Zune 30s and I had made a playlist of songs to play during a New Year’s Eve party.”

Microsoft Corp., maker of the Zune, said a bug in the internal clock driver, related to the way the device handles a leap year, caused the malfunction in older Zune 30GB models.

Matt Akers of the Zune Product Team wrote Wednesday on that the problem should resolve itself after 7 a.m. ET Thursday. The Zune support page says users should allow the internal battery to fully drain, then recharge by connecting the Zune to a computer or AC power after noon GMT (7 a.m. ET) on New Year’s Day.

“Once the battery has sufficient power, the player should start normally. No other action is required — you can go back to using your Zune!” the site says.