BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for January, 2008

Conference call hold music

Posted by BPuhl on January 31, 2008

In case you hadn’t seen it… a couple of Microsoft guys showing what really happens while we’re waiting for everyone else to join in on the conference bridges. 

(Except most of us can’t dance like this)


Posted in Nuggets, Randomness | 1 Comment »

Comparing TripIt vs. Dopplr – TripIt Wins

Posted by BPuhl on January 25, 2008

Seems like the minute that someone has a good idea, along come a bunch of other people with the same idea.  Now, I have no idea which site for travel came first, TripIt or Dopplr, but they both came into my world at darn near the same time.  First, I was reading a blog post talking about how great TripIt is for frequent travelers.  Then within a day, I received an invitation from Pamela inviting me to use Dopplr.  So of course, a side-by-side comparison was required.


Proving yet again that we’ve entered the MySpace [1] age of the internet, the point of Dopplr was to let users manage their travel itineraries while mostly focusing on letting you share you schedule with your list of Dopplr-Friends.  Because I travel quite a bit, it’s pretty cool to me to find out (before hand) whether I’m going to be in the same place as friends.  Unfortunately, you have to manually add your trips.


TripIt is built for consolidating travel schedules into a single, easy to read place.  Very important for the frequent traveller, who is trying to keep hotel, car, train, and airline reservations straight for multiple trips at a time.  The primary benefit of tripit, is it’s continually evolving ability to interpret the e-mails which the various reservation systems send out, and automagically import those into it’s system.  For example, you take your itinerary as sent to you by the airline, and simply forward it to plans@tripit.com and it’s automatically added.  Unfortunately, it’s only “your” trips, and you can’t correlate with your friends.


I’m sure many others have as well, but many months back I submitted feeback to both sites, praising the design of the other and hoping for a merger (or at least poaching) of technologies.  Well, I’m happy to announce that TripIt has the friends options which will allow me to reconcile travel plans with any other friends who use their system.

Now, can I convince Pam to join TripIt?  (Oh yeah, and I love the fact, that to “join”, simply involves forwarding your first itinerary to plans@tripit.com.  If your e-mail addy wasn’t previously registered – ie. first time users – then they provision an account and reply back to you with a verification link.  Now THAT’s the way to go)



[1] – BTW, I believe that MySpace was created when the demon spawn of Satan dipped their bitbucket into the black river of dead HTML, and splashed the contents across a web farm.

Posted in Travel | Leave a Comment »

Multiple RODC’s in the same site?

Posted by BPuhl on January 25, 2008

I mentioned in my previous post, that internally we have been running with RODC’s and full DC’s in the same AD site.  Any great benefit to this (other than the complicated GPO replication issue that I posted about?)  No, not really.  But as Laura pointed out in her comment, it’s useful to remember that while it may not be especially valuable, it’s also not prohibited in any way.

Another common deployment question, is whether or not you can have multiple RODC’s in the same AD site.  There are actually 2 different cases here, so let’s look at them both:

(These comments are based on a standard branch office scenario, with an upstream full DC in a site connected by a WAN to the site containing the RODC’s)

Multiple RODC’s from the same domain, in the same site

From a technical/deployment perspective, there isn’t anything stopping you from deploying 2 RODC’s from the same domain into the same site.  But there are definitely some important gotcha’s to remember:

1.  RODC’s don’t replicate out to anyone – so that means they don’t replicate out to each other either.  Therefore, from a replication perspective, each server will still replicate in from a full, upstream DC.

2.  Replicated passwords are part of #1 – This is important.  If I’m a user in a site, and the site has 2 RODC’s from my domain in them, but only one of them has my password cached.  Then if the WAN link goes offline, and I try to log-on, Murphy’s Law says that DCLocator will find the “other” RODC for me (which does not have my password cached).  In this case, auth will fail, and I will be an unhappy user.  You as the AD admin, will cache a boatload of flack for this flagrant violation of our SLA.


RODC’s from multiple domains, in the same AD site

You would think that this is a good idea, because then all the users in each of the domains could log on, etc… in the site when the WAN link goes down.  And you would be mostly correct.

The gotcha here, is that as part of their increased security stance, do not replicate in the passwords for “critical” or “sensitive” accounts.  For example, they’ll never replicate in the password for a user who is a DA.  Of course, the TDO (Trusted Domain Object) password, is also “sensitive”, so it doesn’t get replicated in either.  What this means, is that an RODC is useful for authenticating users to resources within it’s domain, when all of the necessary passwords have been cached.  However, you can not perform cross-domain authentication without a full-DC being accessible.

Posted in Active Directory, Random Tecnical Stuff | 1 Comment »

Time to Rescue a Damsel in Distress – 8 minutes, 45 seconds

Posted by BPuhl on January 24, 2008

The tools:

One pair of regular scissors

One folding pocket knife

4 years of college education in mechanical engineering

The Challenge:

Remove Princess Annika Barbie and her magic pegasus light-up wand from the plastic packaging


The Procedure:

Began by first carefully cutting away the “sealed” edge of the packaging, allowing me to remove the back panel of protective plastic and lift the entire interior assembly from the front plastic.

Next, seperate the 2 halves of cardboard, revealing the ridiculously complex series of wires, plastic, and string inside which are used to hold the doll and magic wand perfectly in place.

Focusing on removal of the magic wand:  Carefully pull the wand away from the cardboard.  Attempt to slide knife in between, carefully cutting away the plastic tabs holding the upper portion of the wand in front of the critical “press here” opening (it lights up).  Small slip-up, knick index finger of left hand…not bleeding that bad.  Lift wand out of it’s cardboard prison.

hmmm…that was easy….too easy…

Looking again at the back, her arms are held in position by plastic coated wires.  Prior experience with this has shown that these wires are impossible to cut.  Best to spend several minutes peeling the ends of the wires away from where they have been taped to the cardboard, untwisting them, and pulling the arms free from their steely bounds.

Next, comes the hair – How did they get her hair to stay like that?  Using carefully color matched thread, they have SEWN her hair to the cardboard, using a piece of plastic to hold it in place.  Fortunately a quick tug on the plastic and the thread undoes itself – ahhh, you Mattel packaging demons are pretty slick! 

But the first attempt to pull her head away from the cardboard fails as I realize that they used those same little plastic pieces that stores use to attach price tags to clothes – to hold her head in place!  Argh…  snip, snip – head is free.

Oh but wait, there are three more of these, running down her back, making sure that no matter what manner of shaking occurs during shipping, her beautiful dress remains in perfect position.

Lifting her straight up, removing her feet from the holes in the cardboard “box” structure at the bottom


just under nine minutes, no stitches, and only a little bit of blood.  Now, where’d I park my white horse again?

Posted in Anika, Friends and family, Randomness, Rants | Leave a Comment »

Photo’s in AD?

Posted by BPuhl on January 24, 2008

I love the fact that there is a lot of mythology floating around about AD.  Much of it is completely bogus, but hey, at least people are thinking about a problem or scenario, and if they are thinking, then that’s much easier to correct than someone who isn’t thinking at all.

One of the more entertaining things I’ve heard, is that you should never (ever) allow users to store photo’s in AD.  Aww heck, there’s even an attribute in AD, called thumbnailPhoto, so what are you talking about?  Sure, it’s going to be a “large” attribute, meaning you need to make sure that you have enough disk space for your database, but then again, so are certificates and nobody hops up on their soapbox when someone wants to deploy PKI!

Many months ago at Microsoft, we finished an internal project which published everyone’s photo into AD, and an add-on for Microsoft Outlook which allows user to “show pictures” of each person who is on the to line.  This has turned out to be incredibly helpful, when you are going to walk into a meeting and don’t recognize anybody else that’s on the invite.

So what’s all the FUD about putting pictures in AD?  Well…like anything else with AD, it’s not something which you should just go about willy-nilly, how about we stop and put some thought into it?  For example, whatever process you use, shouldn’t allow users to add arbitrarily large images into the directory.  We use a Sharepoint application, to scale down the images to an appropriate size.  You should have some form of life cycle management for the pictures, so that you can make sure that they are updated/maintained with all of the other aspects of the user account. 

You know, in short – You should manage this bit of data in the directory just like every other bit of data in the directory which you manage.  Wrap appropriate controls around it, ensure it’s validity/integrity as necessary, etc…

Actually, the biggest problems with putting images into the directory, are not around the technology of doing so.  There were many (many, many) discussions around whether you wanted to allow people to explicitly “opt-in” to publishing their picture, “opt-out” of publishing it, or “require” them to do so.  After many discussions with our internal legal department, we found that for users in North America, we could publish their pictures without their consent, however the complex privacy laws in other parts of the world led us to providing an opt-in model for those users.  Yeah, this actually did upset some of the North America users, but not too many and not that vocally.

Interesting bit of trivia though – one of the things we decided to do with our deployment, was to allow users to maintain their own pictures, via the Sharepoint application I talked about.  This immediately led to a few different ideas about compromising the quality of this service.  One team, considered having everybody on the team change their images to that of a single person.  Others decided that changing their images to something that was more representative of their personalities, such as them snowboarding or their family. 

Personally, my “corporate avatar” is:


Yes, that’s right – it’s a giant half-chicken half-squirrel.  And if you have absolutely no idea what I’m talking about, then you don’t watch enough South Park (which is probably much healthier for you anyway)

random note:  Picture cache, for those of you who have played with this, is located at:  C:\Users\<user>\AppData\Local\Microsoft\Outlook\PictureCache

(BTW – For all the techy people out here who are looking for some useful nugget of information in all of this blathering – With the deployment of credential roaming in Windows Server 2008, which stores many more certificates, plus these pictures for all of our users, our typical database size has gone from about 13GB to about 22GB.  We still build our typical server with 16GB of RAM though…)

Posted in Active Directory, Babbling and Blabbering, Nuggets, Random Tecnical Stuff | 2 Comments »


Posted by BPuhl on January 24, 2008

Saw a reference to this on fark, and had to see what it was about. Too funny 🙂


Posted in Randomness | Leave a Comment »

Why isn’t my GPO Change replicating?

Posted by BPuhl on January 23, 2008

Real life conversation within Microsoft IT:

GPO Admin:  Why isn’t my GPO change replicating?


AD Admin:  Because it was written to an RODC.


GP:  errr…huh?  I thought the RO in RODC was “Read Only”


AD:  Yup, it is…  but the GPO change was still written to it.  And that’s why it’s not replicating to the rest of the domain.


GP:  HUH?  Explain please.


AD:  Remember that GPO’s actually have 2 parts, there are the files which are written into SYSVOL, and there are the changes which are written to the AD objects.  When you launch GPEdit, it typically connects to the PDC for the AD portion of the writes, but gets a DFS referral for the SYSVOL portion.  Even if you connected directly to an RODC for the AD portion, the RODC will return an LDAP write referral to a full DC, so that write operation will still work. 

However with the DFS referral doesn’t know the difference between a full and an RODC.  So if you connect to SYSVOL on an RODC, then the files will be written/updated as expected.  What you’re seeing, is that because an RODC is read-only, any changes which are made will never, ever replicate to the rest of the domain.


GP:  So, then the AD update worked, so now we’ve got version number mismatches, because the updated files never replicate?


AD:  Yes, but that’s not all.  DFSR will actually detect that this is one-way replication, AND that the files don’t match.  So you’re change will be “fixed” during the next update, when DFSR puts the files in SYSVOL back to their original state.


GP:  wow.

So, it’s important to note here, that the majority of users on our main campus (including our admins) are all part of a single, fairly large AD site.  For this domain, our site includes about 35 full DC’s, and 6 RODC’s.  So it was a little bit of a fluke that we hit this, and I wouldn’t expect it to occur very often if you deploy RODC’s in the typical branch office type of deployment.

But It’s useful to know that RODC’s are actually writeable for SYSVOL, but that if you do writes then those changes will not replicate out and you end up with version mismatches.

Posted in Active Directory, Random Tecnical Stuff, Rants | 2 Comments »

Blogging as documentation?

Posted by BPuhl on January 23, 2008

From an e-mail with a tester in the product group, regarding a behavior with RODC’s:

It depends on how the <component> is written for RODC scenario

<Name> is writing a blog for this particular issue

(Yes, this specific topic will be covered in the Branch Guide as well…but are blogs becoming some sort of parallel to KB articles, etc…?)

Of course, I’ll throw a post up soon as well (for good measure)

Posted in Active Directory, Random Tecnical Stuff | Leave a Comment »

Upgrade Complete

Posted by BPuhl on January 19, 2008

As of about 7:00pm Eastern Time, Mark Arnold and Laura Hunter were married in Philadelphia, PA.

Congratulations Mark and Laura!!!!

Posted in Active Directory, Babbling and Blabbering, Nuggets, Randomness | Leave a Comment »

InfoCards in the Enterprise

Posted by BPuhl on January 15, 2008

Recurring theme lately around the office – When are we going to start using InfoCards and Cardspace internally?  In fact, I was fortunate enough to be part of a conversation recently with several of the smart guys in the MSIT Security team, and although we didn’t come up with anything hard or fast – Here is where I’ll give you “my take” on when we’re going to use InfoCards and Cardspace internally.

Important Disclaimer – Discussions are great for helping you articulate your thoughts, but all opinions in this blog are my own.   Also important to note, that most of the InfoCard and CardSpace discussions are around solving the consumer identity problem.  This is a huge problem to be sure, but I’m an enterprise IT guy – so it’s not the problem which I’m focused on every day.  I care about my enterprise identity management issues.

First – a bit of terminology clarification:


CardSpace – This is the identity selector.  It’s included in Windows Vista, and available for Windows XP, but in short, it’s the “secure desktop” (you know, the bright colorful part of your screen when everything else goes greyish/black)…..(no, not a crash! smart alex, those are blue!)….  The purpose of CardSpace though, is only to allow you to select InfoCards.


InfoCards – These are the things you select in CardSpace (Ha! Bet you didn’t see THAT coming!).  Each InfoCard represents some set of bits of information about you that you want to submit to a website.  There are a couple of flavors, self issued, and managed InfoCards.


Self-Issued – Pop open a browser, and see how the Windows Live, Yahoo, and Google toolbars (I’m sure some of you have all 3 installed) have the “Auto Fill” button?  Yeah, that’s pretty much the idea behind a self-issued card.  Of course there’s some more, combined with identity selector you get some anti-phishing help, so you don’t accidentally auto-fill your paypal user name and password into the paypa1.com website, but conceptually, it’s auto-fill + anti-phishing.  These cards could be useful as replacement for the Post-It notes below your keyboard, which have username and passwords written on them for all the websites you frequent.


Managed – These are cards are actually issued by a server (as opposed to being self-generated), and are more likely to be used to pass information which is stored in a centralized identity store, and vouched for (ie. signed), by that store.  Think for a moment, an application which only trusts information about your user account which came from Active Directory.  A token server could issue you a managed card, which corresponds to your AD account, and whenever you access the application and select the card, then the requested attributes from AD are read and placed into the token.

So if the question is really, when are we going to use InfoCards and CardSpace internally at Microsoft, I think there’s a good chance to say that we wouldn’t.  Now, this doesn’t mean that we won’t, just that the problem which they solve is actually a symptom of a larger problem, which has solutions – albeit, more complex ones. 

Let’s take a look at the scenario’s in which these technologies would provide a good value to our business:

Single Sign-on (Internal) – The purpose of an identity selector, is to select an identity.  Ok.  Probably could have been named a bit more descriptively, but we’ll go with it.  How many identities do you have in an enterprise?  Well, ideally, you want to have one – and that one would allow you to access everything that you need.  Ok sure, but we all know that isn’t how most enterprises work, instead they have many systems, each one with it’s own identity store.  Well, as I’ve said before, if you have an identity store, you immediately get a provisioning problem.  So there are actually 2 ways to solve this problem then – First, you can make it very easy for users to manage their 21 user names and passwords (or whatever it is), and provide them a pretty UI for swapping into and out of applications.  CardSpace fits this bill nicely.  It’s not really SSO, because I count having to select a card as a “sign-on”, but it’s definitely “easier sign-on”, that’s for sure.


Single Sign-on (External) – Isn’t this what federation is all about?  Well, sort of, but the fact is that there are a lot of partners which we can’t federate with.  However, if they were to issue managed InfoCards, or even allow our users to register self-issued InfoCards as their authentication mechanism, then it would help relieve the Post-It note under the keyboard problem.   Still though, this means that your partners are going to need to maintain their own identity stores.  InfoCards will help ease the user pain, but the businesses (and IT guys – like me) still have to deal with the provisioning problems, data consistency issues, and security concerns of allowing a partner to have all of this information.  The better solution would be to federate with our partners, to allow our users to access with their corporate credentials, no UI prompt, “it just worked”.


Role Transitions – Internally, this is something which we have only started to think through, so I’ll describe what we’re thinking – and leave the question of whether or not it’s worth it for later:  If you’re an administrator of an enterprise application, then there is also a reasonable possibility that you are a user of that application as well.  If this is the case, then is there a need/desire, for you to sometimes access the application as a user, and sometimes as an administrator?  Usually, the way that you see this, is that an administrator has the same menu options as a user, plus additional ones.  Is there any reason why this is bad?  To have the administrator role separated from the user role, would be much easier in a CardSpace world because transitioning from user to administrator and back could be done much easier.  But that seems like a lot of work, and it’s never been a requirement to date (at least not for application admins).

There may even be more places where InfoCards and CardSpace can fit into an enterprise.  These are the ones which I have come up with so far.  The pattern which seems to be showing though, is that if you can’t fix your “big” identity management problems, then you can use InfoCards to ease the user experience of them.

Posted in ADFS, Identity and Access, InfoCards | Leave a Comment »