I’ve been messing with powershell for a while now with VMware, but never really getting into big time scripting with it. Its mainly be something to use to accomplish some various tasks on mutliple hosts. Very little error checking in the scripts since I’m watching them was they run. If I want to put them into a scheduled task or automate them from a web page, more error checking is needed.

Recently, we starting messing around with automation of Exchange 2010 provisioning using Powershell. There are some great cmdlets to accomplish this, but I ran into a particular issue that really bothered me as a programmer and since I spent more than 5 minutes unsuccessfully googling the answer, I figured I’d write this post.

My issue was this, I was attempting to put some wrappers around certain cmdlets to get back whether or not they completed successfully. I hate to be the bearer of bad news, but shit doesn’t always run as you think it would.
I think I found a good way of handling the powershell scripts that do not return a true or false and were causing some false positives.

The issue occurred in the functions such as remove-mailcontact where I would have something along the lines of:

This would alway return the -ERR statement.

So now I have expanded upon that and have the following:

This second method seems to be doing what I want and goes to the appropriate domain controller so I think I’m on the right track…we just need to update the various scripts now. For a little more information on the errorVariable adn other default switches you can pass a cmdlet, check out this blog post from the Microsoft PowerShell Blog.

Here is what I’m dealing with. First, let’s go to the documentation on TechNet:

Pretty clear that we have a few required parameters and a few optional ones to set some quotas. These optional parameters are what will soon drive me to uncontrollable rage.

Next, let’s look at the example directly from the web service. Here’s what it states we can pass:

Again, everything looks great. postStorageQuota and storageQuota are both there and seem perfectly reasonable.

So let’s actually SEND that command to the web service. Here’s the error I get back:

You get this is you change PostStorageQuota to prohibitPostQuota.

In case you missed it, they changed the variable with in the back end server code, and failed to tell anyone that they made this change. Awesome!

This appeared only after we made the jump up to HMC 4.5 rollup 9. Before the PostStorageQuota and StorageQuota worked as expected. Needless to say, I’m less than impressed that they changed properties on me and failed to update the documentation OR the web service example. I guess figuring this out with trial by fire is the way that Microsoft expects you to learn. Thanks Microsoft!

But seeing as I’ve had a chance to move up in companies and produce multiple products, I have a different appreciation for product lifespan and code rot.

Product lifespan? Code Rot? What the hell is this loon talking about?

Software is much like owning a house, you have to maintain it. Issues (bugs) are found, new technology comes out that will make your product more stable and possibly cheaper to run. New advances in design and layout require a fresh coat of paint from time to time.

Eventually the software is a bit too much of a mess. Sometimes you have to gut a room or two. Sometimes, you just have to tear the whole damn thing down.

How do you know when its time?

For me, there isn’t one question that clearly lets you know when its time. For example: When was the last time you gave the product any love? When was the last time you added a feature or fixed a bug? When did you give it some marketing dollars? Has it been so long that you can no longer remember? Have you been distracted by other products? When was the last time you had a signup?

Its OK to admit that you have been ignoring a product. But now you have to ask yourself, how much is this costing me a month? How often is support getting calls on it? What are my hosting costs for keeping this around? Am I still making money? Would I have a company if this was my only product?

It quickly becomes clear on what you should do. We have a product at our company that hasn’t done as well as I would have liked. To be honest, it has a lot of issues. Most of which are out of our control. Due to licensing, its priced too high and competes with “free” alternatives even if they are less secure. It has maybe a couple hundred users on it and if it was our only product, we would have shut the doors a while ago. Its time for it to go.

Dealing with the breakup

So the hard stuff now has to happen. You have to either tell your customers to go away, or find an alternative that maybe you’re reselling, maybe not. There is a good chance that they’re not going to like what you are going to tell them. Break it to them easy, give them PLENTY of time to migrate away from your company if they choose. Bend over backwards to any request that they have for getting their data. After all, its THIER data! Helping users move their one service will hopefully keep those customers on the other services that they have with you.

In the end, this is best for the company. Even if you lose a customer or two, its best in the end. Even with the lost revenue, there is hopefully a huge reduction in expenses that can now be pushed to your money making products. And yes, even with repeating this to yourself, it will still suck. Good luck my friends.

Today is one of those days. We launch our revamped customer portal to our internal employees. Let’s hope all goes as planned.

Rule 1: Computers are too hard to use.

Sounds simple, but its still true. I’m in my early 30s and there are a lot of programmers that are younger than me that don’t understand this. They’ve always been around computers so it makes sense to them. Now, put that same computer that you have been flying around on in front of your parents or grandparents. Suddenly, computers are hard to use. This isn’t as big of a problem as it was 5 or 10 years ago. But it is still very much a problem. Especially when you are doing something that no one else has done before.

Rule 2: The internet is too hard to use.

The web changes at the blink of an eye and for the average user, this can be a scary thing. Imagine a site that you have been using for a year or two. You know where everything is, its clearly laid out, and its comfortable like an old pair of jeans. Now, imagine you log into your computer and now it has been updated with the latest web 2.0 technologies. All of a sudden, you have to relearn everything on the site. Hopefully, they’ve done a good job and everything flows the way that it should and the users don’t revolt. Intuitive design is not something that comes naturally to all developers. For some sure, but for many they think about completing the tasks that they were assigned and it works for them because they developed it. A/B testing, User Acceptance Testing, all foreign concepts to this type of programmer.

Rule 3: People are stupid.

Wow, I could go on this one for a while. But unfortunately, there are certain users no matter how good your design is, how good the on screen help is, and how good the training / manual is, they will find a way to be confused or break your application. Every day, the world is creating a better idiot.

Here’s one of my favorite examples:

At my last job with our hosted email product, we allowed users to forward their mail to an outside account. Many of which forwarded to their AOL accounts. Normally this wouldn’t be a huge deal except that many AOL users take the “report spam” button and the “delete” button to be the same thing and are located way too close together. To the end user, it does the same thing. The message goes away. But to system administrators, this gets your servers blocked when the “report spam” link is used. Could this be too many people mis-clicking? Could this be people not reading? Could this be people being stupid? The answer may be all of the above. But eventually, it comes down to, no matter how clearly the button is marked, how clearly it is laid out. People will still surprise you with how stupid they can be.

Yes, it sounds mean and I’m not going to say that I haven’t done something stupid on a computer. I have, I can admit that. But even I can admit that I was stupid after I realized that I had done. It happens to the best of us. At the end of the day, it all comes back to the developer/designer though. You failed to make your application intuitive and when someone does something that you weren’t expecting, you didn’t fail in a graceful way that got the user back on track.

Call to Action!

So what can we do as programmers and designers? Well, remember that the internet is a wonderful place and that 80% of your users will never have an issue. Its the 20% that makes it hard and we will constantly be working to make the internet a better place.

I follow this simple rule when programming: How would my dad use this application? He falls into rule #1 and rule #2 due to his age and his former career. He’s a retired elementary gym teacher so he didn’t have to use a computer all that often. He uses one now at home quite often and does well, but he’s still intimidated about messing something up. So if I can put in graceful failures, useful dialogs and whatever other help I can give him along the way, this helps make my applications as usable as possible.

This one I thought was pretty easy if you are a geek. And seeing as my blog is pretty tech related, I figured that a lot of people would get this one. Maybe its just me, but when I see certain encoded lines, I can pretty much guess that they are encoded with base64. Maybe I’ve been around email too long.

So if you took our fabulous line and pasted it into any one of a million base64 decoders out there, you would get the following:

With faith and hope, the dream begins anew

It was also a somewhat recent facebook status of mine. The new cryptogram will be coming out in a few days. Stay tuned!

Without further ado, here is the first cryptogram.

V2l0aCBmYWl0aCBhbmQgaG9wZSwgdGhlIGRyZWFtIGJlZ2lucyBhbmV3

Good luck!

For each cryptogram, the solution will be posted the following Monday.

Update: Answers are posted on Wednesday, not Mondays.

Today was another day for battle. And an interesting battle it was.

So here is the situation that I was running into. Within my code in the customer portal, I have a notification that is sent out that has a full back trace of what happened on the system, what was inputted and what was the error message that was returned. I of coarse try to give the user a friendly version of the error message to the screen before sending off this plethora of valuable detail. Out of this pile of data, I find the following error message has been returned:

“A device attached to the system is not functioning”

Really? Let’s look at that again. Because surely no one in their right mind would return such a generic error!

“A device attached to the system is not functioning”

Hmm, my clue-by-four hasn’t been brought out recently and plane tickets to Redmond aren’t that expensive right now. I guess I could go out there and start handing out clues. But why would I need to. This error message is clear and concise. A device attached to the system is not functioning. What more could I possibly need from this error message. It gives me everything I want! There’s a device, its one of 30 or so devices in the system, that is not functioning.

HOW ABOUT WHICH DEVICE YOU FUCKTARDS!!!!!!!

So we check out the domain controllers, the MPS servers, the web servers, OCS pools, exchange queues, look at SCOM alerts. Nothing pops out at us. Then I take a look a bit further at the error message. here is the full error message that I get back:

The CreateSamObject_ raised a red flag to two. If you search Google long enough you’ll eventually find something from MSDN stating the following:

From MSDN:

User account names are limited to 20 characters and group names are limited to 256 characters. In addition, account names cannot be terminated by a period and they cannot include commas or any of the following printable characters: “, /, \, [, ], :, |, <, >, +, =, ;, ?, *. Names also cannot include characters in the range 1-31, which are nonprintable

Eureka! We have found the issue!!!

The sAMAccountName for our system is pretty generic. Cut down the upn to 16 characters. Add a period and a unique key that we keep for each of our domain names. This way, the chances of you duplicating names both inside and outside of your OU is pretty limited. However, in this case there was an error with retrieving the unique 3 letter key for the end of the name so the sAMAccountName that we were attempting to set looked something like this:

This was an easy fix once we found the issue. But man, could there be a crappier error message from HMC? I mean seriously, how do you get from unable to create the sAMAccountName to a device attached to the system is not functioning?!?!?

Anyway, I figured that I would type this up, let the search engines find it and hopefully someone else can benefit from our digging through the depths of HMC.

Background
A long time ago, we had a very crappy provisioning system for our hosted Exchange 2003 platform. It worked ok, but missed a lot of things that we wanted to have set. They also were kind of pricks when it came to licensing so making a ton of money on the platform was hard to do. So, we decided to roll our own. It wasn’t that hard to reverse engineer what was being set for users, groups and contacts. There were a few obstacles of coarse but we were able to get a pretty good provisioning system setup. However, this too had its faults. Sure we had total control over the code and could update things as we needed. But we were still working in a void. We really didn’t know _everything_ that was happening on the system that needed to actually happen. Plain and simple, we were missing things. Not to mention future services would require the same amount of dev time reverse engineering what needed to be set. That’s not a scalable solution.

So, when it came time to roll out our Exchange 2007 environment, we have moved over to HMC and for the most part, things have been a lot happier.

The Issue
Since we have this shiny new 2007 platform, we thought it was in our best interest to start migrating our users from the 2003 platform and away from the old clunky provisioning. So far we have moved some smaller customers and everything has gone pretty smooth. Certain customers have required the migration to happen in stages so we have come up with a decent solution to make this as smooth as possible. We define the list of users to migrate, setup a temporary domain on the 2003 platform, add smtp aliases to the users on the 2007 platform and then enable forwarding on the 2003 platform to the 2007 temporary smtp alias. All mail still flows as it did before, its just that some users happen to be on the 2007 platform getting their email. Easy as can be right?

Well, the users that we have moved so far have been fairly small customers. So the need for automating certain aspects of the move have been put off. There is a lot of automation that happens, but some of the tasks were put off such as the setting of the forwarding address.

That is, until last week. Last week we were starting to move one of the bigger customers so I setup a script that would take the users that were being moved and automatically set the forwarding address. Here is the code that I had in place to figure out the forwarding address:

Notice the $fwd variable. This is where the trouble begins. You can ignore the {} as those simply tell the parser that these are valid variables contained within the string.

No, the real issue is at the end of the line. Specifically, the \n. Technically, you can set the AD object to whatever you want. It will take this as a value. However, Exchange does not like this. With forwarding in exchange, you set the forwarding to an object. Typically another user, group of contact. Since we allow for users to forward to multiple people, we create a group automatically and populate that with one or more users, groups or contacts.

Now for the really bad part. I’m not sure if this is just Exchange 2003 or if others are affected as well. But when you forward to a group that contains a single contact object that has invalid characters, your email message with be lost in the ether. Gone, Kaput, Not even an NDR will be generated. We were unable to even find logs that the message came in it failed that spectacularly.

Conclusion
So the moral of the story is, don’t do what we did. Microsoft will tell you the exact same thing. Its dumb to do what we did. You should not be messing with the AD attributes directly in this instance. There is a certain level of error checking that must take place at the upper levels which were missed by both my script, and the provisioning system. But in the same breath, I can’t say for sure that HMC was mature enough to use when we first rolled out the 2003 platform. So whether it is you editing AD directly or someone else doing it, its just as bad. It just depends on how much control you want over the gun pointed at your head.

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 “(bar@domain.com) 1 results found.” Unfortunately, we were getting false positives on our searches. bar@domain.com does not exist on our BES system. However, foobar@domain.com does. So if you search for bar@domain.com, what you are really search for is *bar@domain.com* 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 “(bar@domain.com) 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 foobar@domain.com!

The solution was to now search the verbose (-v) results for SMTP:user@domain.com and we would now get the desired result back. We would no longer find foobar@domain.com when we really wanted to see if bar@domain.com 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 bar@domain.com and NOT *bar@domain.com*