Notes on Windows Phone 7 update process thus far

Windows Phone 7 updates are slowly making their way out to users. Two hot questions in the technical community, however, are: How does my phone know when an update is available? How does Microsoft differentiate my phone from others that have received the update?

As you may know, there are two ways to determine if an update is available. Your phone can either notify you via its internal, scheduled check (Settings –> Phone Update) or you can request an immediate status via the Zune client (Settings –> Phone –> Update). In both cases, the phone (not the Zune software) securely communicates with the familiar Microsoft Update services (update.microsoft.com) via the Windows Update Services protocol. (It’s cute the Zune software tells the phone to check for updates, which it does… by looping back through the Zune pass-through connection.) In order, the phone…

  1. … checks for Microsoft Update (MU) services location, if cached location is stale
  2. … gets the configuration of MU [details]
  3. … gets a token for MU service communication, if one isn’t cached [details]
  4. … syncs update information with MU [details]

Of note is the high volatility of the information received from MU when syncing in step 4. On February 26, for example, the data returned was chock full of “applicability rules”, which are used to simply determine if an update should be installed, like such:

<IsInstalled>  <Not>
    <CspQuery LocUri="./DevInfo/Man" Comparison="EqualTo" Value="SAMSUNG"/>
  </Not>
</IsInstalled>

I suspect the Samsung rules were added in response to recent bricking incidents. (Carrier-specific and Omni-specific rules were in place too.) None of these rules appear in a dump I created March 5th though, possibly suggesting Microsoft is either gearing up for a blast-everyone update or someone hit the big red “stop updating phones” button in response to repeat bricking incidents. (Or both.)

Unfortunately, I haven’t exactly wrapped my head around how Microsoft has MU set up. In the snippet above, for example, the IsInstalled element specifies which conditions need to be met for the update to be considered as already installed. On my Samsung Focus, IsInstalled would be set to false (note the Not logic) implying the update would be offered for install. But the update’s Action element is set to Evaluate, which prevents this. I suspect this is because an update must be eligible for installation to actually be blockable; I’m not sure what the disadvantage is in having one update with a huge list of eligibility rules vice many updates with one rule.

I’m still poring over the dense documentation [MS-WUSP] but could really use a hand. If you work with this stuff at Microsoft or are a Windows Server Update Services (WSUS) expert, do email me. I’ll keep you anonymous, if needed.

In an attempt to get more details, I contacted Microsoft on February 23 and March 4. I was rejected both times. We're still friends though.