The Joys of SPNs

Last week I was at TechEd in LA and spent some of my time listening to Mark Minasi talk about Kerberos in Active Directory. He spent some time talking about SPNs (Service Principal Names). The takeaways were:

a) They needed some love and care when creating them manually.
b) That you really didn't want duplicates of them lying around in AD.

I've dealt with SPNs on occassion when dealing with delegating connections between SQL servers for one of our in-house applications and always remember it being a confusing process that I never spent enough time to seriously understand. So I nodded to myself in agreement with the speaker and moved on.

Then I came back to work. One of our on-going projects required serveral of our company SQL servers to be moved from one domain to another. Our DBA was responsible for planning this work, since he'd ultimately be the one fielding the support calls if things went bad. And he decided to work on this yesterday, tapping me to help out with anything that fell into the realm of Active Directory.

The key troublemaker in all of this? SPNs.

It can be tricky to find old SPNs when you aren't really sure where to look, and since we were never really sure of what we'd done in the past, knowing where to look was a factor. It's also hard to tell if you are doing things correctly using the SetSPN Tool that comes with Server 2003, as it lacks some of the improved features of the Server 2008 version. Also, we had a lot of moving parts involved - changing the domain membership of the servers, changing the service account that runs the SQL Services on each server and the additional issue of forgetting to check that DNS was updated properly.

The big helper in all of this? ADSIEdit.

Once we realized where we were supposed to look (at the service accounts, not the servers themselves), it made adding the new SPNs and remove the duplicates really easy. And now I really think I understand how SPNs work - instead of my previous attempts of just mucking around and getting lucky.

Customer Focus Design for Window Server with PacITPros

On May 5th, I helped organize a special event for the Pacific IT Pros user group in San Francisco. Customer Focused Design is a process used by Microsoft to collect feedback about features and requirements that need improvement in future product development.
The goal of this event was to provide Microsoft with feedback related to the future of the Windows Server operating system. The Customer Focused Design team was very appreciative of the time PacITPros spent brainstorming together to during the session. They saw a lot of really good ideas and value come out of the session. Overall, the three groups provided over 300 individual requirements and close to 50 high level requirements where improvements could be made.
That information was distilled into the following series of slides:Group 1 (Kevin Lane) - 15 high level requirements, with 97 individual sticky requirements.Group 2 (Robert DeLuca) - 18 high level requirements, with 54 individual sticky requirements.Group 3 (Pat Fetty) - 16 high level requirements, with 174 individual sticky requirements.
The slides highlight the following information:
"Customer Importance" - this provides the prioritization of the requirements that were generated.
"Current Ability" - This is the PacITPros ranking of Microsoft’s ability to deliver this requirement right now based on the technology Microsoft provides in Windows Server 2008 and Windows Server 2008R2. The ranking numbers are:
1 = Microsoft doesn't deliver this at all
2-3 = you can do this with significant workarounds and/or 3rd party solutions
4-7 = Mircosoft delivers this with minimal workarounds or other applications
8-9 = Microsoft delivers this with no workarounds
10 = Microsoft couldn’t do this any better
"Improvement Pareto" - The requirements and the ability rankings are calculated together to determine the improvement areas needed for focus. Areas with high importance but low ability are areas that Microsoft needs to put some work into. Areas that are low mean that Microsoft needs less investment and effort to deliver what is needed.
Kudos to all the PacITPros members who participated. This was a hands-on way to have our voices heard directly by Microsoft.

The Kindle - A Quick Little Review

I've had my Kindle for all of 4 hours and I think it's really cool.

The screen is really easy to read, it's simple to navigate and pretty darn straight forward to use. The wireless connection makes it really handy to download books, search wikipedia.com and it has a built in dictionary so you can look up words on the fly.

I bought it because I'm really sick of carting books around and not reading when I have time to read simply because I don't have something interesting handy. I've downloaded a bunch of sample chapters of some books I've wanted to buy and imported a few PDFs of books I already own. I've been using a free software download to do the file conversion - results vary depending on the complexity of the PDF, of course. Documents that are primarily text converted pretty nicely. The big study guide for my Microsoft exam is so-so. You can also email documents in various formats to it directly and Amazon will do the conversion for you and then deliver it automatically.

I know some people has DRM issues with the whole thing. I'm not too concerned. Sure, if you buy a book from Amazon it's in the Amazon format, but its available to transfer to other Kindle devices registered to your account (like a family member) and you can delete and re-load then as often as you want.

You can also download a lot of free books from manybooks.net and Feedbooks provides a downloadable index of their books that you can link to directly from the Kindle and download the books on the fly. Lots of classics, etc.

And seriously, having an easy way to read those crazy Microsoft white papers I feel like I'm always printing. It's totally worth it.

When Things Work.

This morning, I've been at the office. I needed to make a key change with our imaging system that affects the user's logons, so it's one of those things you can't do during the business day.

And due to the additional security features we have turned on for the system, sometimes regular changes to the system actually break things. I don't really like broken things, thus have given myself the entire weekend to fix anything that could have potentially gone wrong.

But it worked. Just like the documentation was supposed to. I appreciate that the tech just sent me their internal documentation, instead of making me rely on them to hand me information only when things start going wrong. Plus I didn't have to make one of them actively work on the weekend and I end up understanding the system better overall because I was doing the work myself.

I did have a tech available via email - but that was more for moral support. He would have only jumped on if things went badly and we had to roll back the changes. But I hate rolling things back - I really like to just fix the problem and keep moving forward.

The Internet Life

Do you remember life before the Internet? I barely do.

It's hard to imagine that there are some people I know best (or only) via the WWW. I was chatting with a friend the other evening and he commented on how he's got a better handle on my personality via IM than he ever had from dealing with me in person.

Maybe that's because when we see each other in person it's always related to our jobs and there really isn't much time to talk about anything other than technology. Not that we don't spend most of our online time talking about technology and work too, but the other night we got onto other topics that probably would never come up when we happen to be in the same room.

It all got me thinking about how I interact with people via some kind of online chat - I'm in the age range where it's not the most used medium for our generation, but I spent so many years developing relationships with remote co-workers that were exclusively via IM maybe I'm just more comfortable expressing myself that way.

There are a lot of people on my chat client list that I don't regularly chat with anymore, but it's nice to see them there throughout the day. I remember when one of my old colleagues switched jobs and wasn't able to connect to IM from his office. I went through weeks of being really unnerved by the fact that he wasn't showing up on my list. It was like some put up a wall between us that I couldn't figure a way around.

Then there is another tech friend of mine who I know is pretty much accessible anytime. He's not always on IM, but if he's got a phone signal he'll usually get back to an email or a text. I sent him tech question yesterday knowing full well that was skiing in Canada. I wouldn't have minded if he waited until he returned to get back to me - but sure enough he replied within 10 minutes. Is it better for him that he's that totally connected or is it a pain in the ass?

Maybe because we both are in an industry where we are available to be paged or alerted by our office servers when they are in need, we don't mind being available to real people, too.