DevDog | /usr/local.com

Powershell Error checking

March 8th, 2012 | by matt | devdog, tips & tricks

Mar
08

Being a programmer by trade, I get thrown into many projects that aren’t always my forte, but I can figure them out and get them working the way that I want.

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:

if(remove-mailcontact -identity $ID -Confirm:$false)
{
"+OK Contact Removed"
}
else
{
"-ERR Unable to remove contact."
}

This would alway return the -ERR statement.

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

Remove-Mailcontact -Identity $ID -Confirm:$false -DomainController $DC -ErrorVariable:err
if($err)
{
"-ERR Unable to remove contact"
}
else
{
"+OK Contact Removed"
}

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.

Comments Closed

HMC CreateFolder

September 9th, 2011 | by matt | devdog, micro$oft

Sep
09

Today I had the chance to get back to some code for CreateFolder which creates a public folder within our Exchange 2007 environment support by Microsoft’s Hosted Messaging and Collaboration frame work. I’ve been highly critical of Microsoft’s code before, and today has taken that to a new level.

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:

POST /mpsws/ManagedEmail2007/Service.asmx HTTP/1.1
Host: prov01.bacon.lightedge.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://provisioning.microsoft.com/webservice/managedemail2007/CreateFolder"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<CreateFolder xmlns="http://provisioning.microsoft.com/webservice/managedemail2007">
<CreateFolderRequest xmlns="http://provisioning.microsoft.com/managedemail2007">
<Data>
<organization>string</organization>
<preferredDomainController>string</preferredDomainController>
<name>string</name>
<path>string</path>
<server>string</server>
<maxItemSize>string</maxItemSize>
<postStorageQuota>string</postStorageQuota>
<storageQuota>string</storageQuota>
</Data>
</CreateFolderRequest>
<sendCredentials>boolean</sendCredentials>
</CreateFolder>
</soap:Body>
</soap:Envelope>

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:

The element 'CreateFolder_Request' in namespace 'http://provisioning.microsoft.com/exchange2007provider' has invalid child
element 'postStorageQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'. List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'.The element 'CreateFolder_Request' has invalid child element 'postStorageQuota' . List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' .

You get this is you change PostStorageQuota to prohibitPostQuota.

The element 'CreateFolder_Request' in namespace 'http://provisioning.microsoft.com/exchange2007provider' has invalid child element 'storageQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'. List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'.The element 'CreateFolder_Request' has invalid child element 'storageQuota' . List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' .

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!

Comments Closed

When to kill a product

July 11th, 2011 | by matt | devdog, tips & tricks

Jul
11

I’ve been out of college now for more than a decade and have worked for only a handful of companies. For a lot of people my generation, I’m probably seen as a dinosaur by not changing jobs every year once my stock options were vested.

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.

Comments Closed

Shipping Code

February 1st, 2011 | by matt | devdog

Feb
01

As a programmer, I have had the joy of seeing a lot of my code ship with various projects in my career. One thing that I have found is, no matter how much I have tested, no matter how solid I feel about the code, there is always that moment of anxiety right before it ships. Its a natural feeling as a programmer to have these. You constantly strive for perfection but in the back of your mind you know that you’re a human who makes mistakes.

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

Comments Closed

3 Rules

January 17th, 2011 | by matt | devdog, tips & tricks

Jan
17

There are 3 basic rules to software programming. Most people don’t know them. Or if they do, they probably don’t know how to properly articulate them. So I’m going to spell out the 3 rules for you. This was talked about a lot at my last job early on when dealing with problems and support issues. Just about everything came back to one of these 3 rules, and unfortunately, rule 3 was more popular than even we believed.

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:
aol report spam button

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.

Comments Closed