Flickr Challenge

A while back, Tony challenged me to the Flickr photo-a-day thing. I intended to do it, but never really got the time.

I’m thinking that as the holidays approach and work continues to wind down for the holidays (we passed our decision points, which is good, so we’re not in Powerpoint hell anymore), I might have more time to explore this. I need to read up on the rules and decide if I can live with taking pictures of myself. We’ll see.

It’s hard for me to take pictures of myself or even look at them. Not sure why. It might have to do with some skin tags or something. Who knows. We’ll see if I can bring myself to do it.

A Visit to Mission Control

If you were subscribed to my Twitter feed, you would have known in near real time that today I had one seriously exciting treat. I managed to squeeze my way into a tour group being led by the incredible Jack Garman here at Johnson Space Center. Think I would turn down such a chance? Absolutely not. Not only is Jack Garman a wonderful friend and professional mentor to me… today I learned much, much more about him… and I’m in simple awe. (Read the Wikipedia entry).

Even juicier, STS-126 is going on right now. While we were going through the MCC, we could see that the astronauts were in the middle of a spacewalk. They had been at it for about three hours when we walked around and examined all the folks at work.

It was just an incredible experience. The geek in me has truly been touched. We were allowed to take non-flash photos. All I had on me was my iPhone and never have I felt like I wanted to beg Steve Jobs for a better camera. Argh!

Anyway… cell phones aren’t allowed, so I put the iPhone in airplane mode and started taking pics. These aren’t all of the pics, but some of the better ones. Most of them are blurry (THANKS STEVE) and off-color, but salvageable with some work I GUESS… STEVE.

Here’s some of them. I’ll post a full album when I get home and have access to MobileMe. I only have iLife ’06 on this Macbook.

Reblog this post [with Zemanta]

Where Powershell Fails

I’m all about negativity today. Sorry.

Anyway, I’ve had something nagging at me for a while now and I think I’ve just figured it out. Powershell is Microsoft‘s answer to having a dumb command line through the Win95 – Win2003 years and it’s quite powerful, as the name implies. Microsoft likes it so much that they makes most of the Exchange 2007 administration efforts in the Exchange Management Shell, a derivative of Powershell that contains Exchange-specific cmdlets.

I’ve long bemoaned to our internal support personnel… and… well, probably my Microsoft contacts too… about how discombobulated Powershell actually is. It’s like it was designed with no standard in mind for the commands – each developer wrote their own cmdlet with their own switches and methods to do things the way they saw fit.

But it’s actually worse than that. Now I’ve come to realize that the problem with managing Exchange from the shell is not only because of the lack of standardization, but because a great deal of this SHOULDN’T be done in a shell command. I’ve heard that Powershell was designed to attract Linux admins who prefer the command line and that’s fine. But I do not know of a Linux admin who would type a command to set a disclaimer on the entire Exchange organization, but rather he/she would edit a config file of some kind. That way, not only would the disclaimer setting be readily apparent and visible, but it wouldn’t take some obscure command to be executed to show me the meat of the option.

What tripped this realization was this “power tip” when I just went into the Exchange shell on one of our servers:

Tip of the day #58:

Do you want to add a disclaimer to all outbound e-mail messages? Type:

$Condition = Get-TransportRulePredicate FromScope
$Condition.Scope = "InOrganization"
$Condition2 = Get-TransportRulePredicate SentToScope
$Condition2.Scope = "NotInOrganization"
$Action = Get-TransportRuleAction ApplyDisclaimer
$Action.Text = "Sample disclaimer text"
New-TransportRule -Name "Sample disclaimer" -Condition @($Condition, $Condition2) -Action @($Action)

Why am I not looking in a config file for this information? Fail.

Reblog this post [with Zemanta]

When RUS Strikes

One item you’ve probably learned by now if you’re an Exchange admin working on a 2007 deployment is that Microsoft has changed the behavior of the recipient update policy.  Most of you won’t care about this and that’s just fine.  You shouldn’t.  I would dare say that if your Exchange environment is engineered well and planned out the way Microsoft probably expects it to be, you should have almost no issues whatsoever.

Consider, however, if you’ve deployed Exchange with some type of “non-standard” approach.  Yes, please picture air quotes around that.  We’re trying to be politically correct here.  What if your Exchange deployment wasn’t, for instance, master of all mail within your TLD?

Let’s say you have a TLD of contoso.com.  Now let’s say you set up an Exchange service forest called services.contoso.com (see my earlier post about why an Exchange service forest is a Bad Idea).  Now let’s say that because there are many other businesses and entities within contoso.com that route their own mail, the decision is made that Exchange cannot be authoritative for all mail coming in to contoso.com.  You need to forward it up to some traffic directors at the top level to determine where the traffic goes.  Now you have Exchange installed in a service forest and you’re not authoritative for contoso.com.  So let’s say you decide to become authoritative for mail.contoso.com.

Now your recipient policy probably says that when new users are created, give them a service.contoso.com and a mail.contoso.com SMTP address.  What about the contoso.com address?  Well, since you’re handling that elsewhere, a third party process has to come in and manually assign that address.  Fine.

Now in 2003, once the user object is created and the addresses are stamped, RUS will never touch the object again and muck with it unless you forcibly tell it to do so.  Believe me though, it’s rare in this setup that you’ll be running this manually.

When you begin to roll out Exchange 2007, you get a new issue.  If you’re configured in this manner and make any changes to the user object… say… moving a mailbox or anything of that nature… then you’ll notice that RUS will take your user object and mangle it up according to what it thinks the SMTP addresses should be.  It’ll reset the primary address.  Fun.  Now your users start to complain that their mailing list memberships are failing, their business cards are incorrect, yadda yadda.  Yes, the behavior of RUS changed in 2007 from 2003.  Take note of it, because if you’re set up in a wonky way that prevents you from being authoritative in your domain, this is going to bite you once for every user you have.

Reblog this post [with Zemanta]