Cryptogram #1 – Solution

February 17th, 2010 | by | devdog

Feb
17

So, its been a few days, did you figure out the solution to our first cryptogram?

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!

Comments Closed

Cryptogram #1

February 12th, 2010 | by | devdog

Feb
12

So I’m experimenting with a little contest to see how smart my 3 readers actually are. Every couple of weeks I’m going to post a puzzle. They’ll be pretty easy to start off with and get increasingly more difficult as time goes by and I have time.

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.

1 Comment »

A device attached to the system is not functioning

August 30th, 2009 | by | devdog, micro$oft

Aug
30

As you’ve read before, I’ve had a variety of battles with the Hosted Messaging and Collaboration framework from Microsoft.

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:

Server was unable to process request. ---> Unable to create 'cn=user@domain.com'./A device attached to the system is not functioning. (Exception from HRESULT: 0x8007001F)/Create Object -- ><response><errorContext description="Unable to create'cn=user@domain.com'./Adevice attached to the system is not functioning. (Exception from HRESULT: 0x8007001F)/Create Object" code="0x8007001f" executeSeqNo="58"><errorSourcenamespace="Error Provider" procedure="SetError"/><errorSourcenamespace="Managed_Active_Directory" procedure="RethrowError_"/><errorSourcenamespace="Managed_Active_Directory"procedure="TryCreateSamObject_"/><errorSourcenamespace="Managed_Active_Directory"
procedure="CreateSamObject_"/><errorSourcenamespace="Managed_Active_Directory" procedure="CreateUser_"/><errorSourcenamespace="Managed_Active_Directory" procedure="CreateUser"/><errorSourcenamespace="Hosted Active Directory"procedure="CreateUser"/></errorContext></response>

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:

&lt;property name='sAMAccountName' &gt;
        &lt;value&gt;user_domain.&lt;/value&gt;
&lt;/property&gt

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.

Comments Closed

One Character == World of Suck

June 7th, 2009 | by | devdog, sysadmin

Jun
07

Ladies and Gentlemen, today you are going to learn a lesson on why you do NOT edit the active directory directly for exchange attributes.

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:

            // need to add forwarding address here.
            list($tuname, $tdmn) = explode("@", $user['mail']);
            // new address
            $fwd = "{$tuname}@{$newdomain}\n";

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.

Comments Closed

BESUserAdminClient.exe find issues

June 5th, 2009 | by | devdog

Jun
05

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 “(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*

Comments Closed