Wednesday, May 23, 2007

How I Managed To Successfully Update My Zune to 1.3

Until today, I haven't been able to update my Zune from firmware version 1.2 to the 1.3 release, which has been out for about 1.5 months now.  I would get the screen inside of the Zune software (running on my computer) stating that there was an update, but when I tried to actually install it, the software would simply stare back at me with a messagebox stating "It is not possible to change sync settings at this time. Try again later."

Searching the Internet proved that others were having the same issue, but there wasn't a clear explanation about what the problem was, or more importantly, how to resolve it.  It also seems that this error message is generic in nature: if any problems at all are encountered while trying to upgrade the firmware, you get this message box.  (That's my disclaimer to state that what worked for me may not work for you)

In typical fashion, there were a lot of posts saying "ZOMFG, Microsoft is teh sux0rz...  Screw dis, I'm buying an iPod".  But, I personally love my Zune, so I made it my morning mission to figure out what was wrong, and then fix it if it turned out to be something that was under my control.

My particular environment (details that matter, in this case):

  • Windows XP SP2
  • A corporate network using ISA Server (that requires authentication against Active Directory) for web proxy.  Note that I never attempted the upgrade from home or any other network - I just never thought about the firmware except while at work.
  • I log into my machine as a local user and have password rules established for network resources (Control Panel -> User Accounts | Manage My Network Passwords).

The first thing that I did was try to find where the new update might have been saved to my disk (to see if it actually existed, and then to see if there was a way that I could manually install the update).  I found the following (hidden) directory:

C:\Documents and Settings\yourUserNameHere\Local Settings\Application Data\Microsoft\Zune\Firmware Updates

Inside was another directory with a GUID name:


And inside of that, a lot of zero-byte files like: BIT6A4.tmp, BIT4C2.tmp, etc.

Hmmm... That looks an awful lot like temporary files for the Background Intelligent Transfer Service (BITS).  Since there were scores of these files (roughly coinciding with the number of times that I've attempted to install the update), I think that I found an important clue.

I fired up Fiddler, the HTTP Debugging Proxy, and started logging HTTP traffic that took place on my machine.  I then selected "Check for Zune Device Updates" within the Zune software (context menu for the device itself), and observed the resulting HTTP traffic. 

One request retrieved an XML document from a Zune server that contained information about the latest firmware version, including a link to the updated file.  There were actually 3 HTTP requests that occurred before the XML itself was returned: the first tried without proxy authentication, and failed with a 407 status code.  The second was to get the NTLM challenge from the proxy server, and also resulted in a 407.  The third was the same request again with an appropriate NTLM response in the Proxy-Authorization header, and this time, the resulting status code was 200 and the payload from the remote web server was successfully returned.  The user agent for all three of these requests was "Zune/1.3.5728.0", so it was the software itself trying to make the connection.

Note: This might seem like a noisy exchange, and it kind of is, but this is what happens behind the scenes when you web browser makes HTTP requests using a proxy server and NTLM authentication.

Another request, which tried to get the updated firmware CAB file itself, would fail with a status code of 407 in the same fashion as the very first web request made by the Zune software.  Interestingly enough, the user agent for this request was "Microsoft BITS/6.6", confirming my suspicion that the Zune software uses BITS to download the firmware images.  Furthermore, as soon as the 407 came through, the error messagebox displayed in the Zune software, and no further attempts were made to negotiate authentication with the proxy server by the BITS service.

At this point, I concluded that the Zune software was able to connect to the Internet, but the BITS client was not. 

Since I couldn't change the Zune software, I looked around to see if I could force the BITS client to authenticate against the proxy server, just like Internet Explorer (and even the Zune software itself) does automatically.  One option sounded promising: I could set up a small proxy server on my computer that would accept an unauthenticated request, but would then authenticate with the real proxy server when it forwarded that request to the Internet.

Luckily, though, I stumbled upon the following KB article:

Interesting snippet from the article:


BITS 2.0 clients may not successfully complete the transfer of a file

HTTP 407-Proxy Authentication.

Note When the BITS 2.0 client receives this error message, it may also receive error code 0x80190197.

This problem occurs when all the following conditions are true:

  • The client program that is using BITS 2.0 does not specify that the credentials of the client can be used by calling the IBackgroundCopyJob2::SetCredentials method.
  • The Microsoft LAN Manager compatibility level (LmCompatibilityLevel) on the BITS 2.0 client contains a value that is set to 1 or to 0. You can find the LAN Manager compatibility level entry n the following registry subkey:

  • The file transfer is performed through a Windows-based server or a Windows-based Internet proxy server that requires Integrated Windows authentication.

Authentication behavior in BITS 2.0

For security reasons, to avoid passing credentials to any proxy or server that requests logon credentials, BITS 2.0 allows logon credentials to be used only if one of the following conditions is true:
  • A program prompts for credentials to be applied by calling the following function and similar parameters:
    IBackgroundCopyJob2::SetCredentials. (target=ProxyorServer, Negotiate/NTLM, username=NULL,password=NULL)
  • If the LmCompatibilityLevel value on the client is set to a value that is greater than or equal to 2.

Important By default, Windows XP sets the LmCompatibilityLevel to 0. With BITS 2.0, logon credentials will not be used if the LmCompatibilityLevel is set to 0.


Now I was getting somewhere!  I checked the registry, and LmCompatibilityLevel was indeed set to 0, which exactly explains why BITS was not automatically authenticating with the proxy server.

Before changing values, I used the BITSADMIN program (you can find it on your XP CD-ROM in Support Tools) to see how many BITS jobs existed (bitsadmin /list) and then cleared out the list (bitsadmin /reset).  This eliminated the scores of failed (inactive) jobs that were still hanging around.

I then changed LmCompatibilityLevel to a value of 2, and then restarted the BITS service, reset the Zune (hold the Back Arrow and Up at the same time until it resets), and restarted the Zune software.  This time, the firmware CAB file was successfully downloaded by the BITS client, and the moment that this finished, the Zune client proceeded with installing the firmware onto the device.


Note: The reason for this BITS behavior is based on security: you really don't want background processes to be automatically authenticating with servers on your behalf if you're not aware of what they might be doing.  The nature of BITS is that you can disconnect from one network, and later connect to a different network (maybe at a coffee shop), and your download will resume automatically without requiring any action on your part.  So, if you do happen to change your LmCompatibilityLevel in order to upgrade the Zune, then be sure to change it back when you are finished in order to preserve your system's integrity.

Friday, May 18, 2007

RDP Console Session: Did You Know About It?

I continue to be surprised by how many IT professionals that depend on Remote Desktop to access servers for administration do not know about this:

For Windows 2003 servers, you can use the following:


mstsc /v:whqs7610 /console

(without the “/console”, it just connects regularly.  With “/console”, you grab the actual console session, as if you were at the monitor and keyboard downstairs in the server room).

Out of the box, Windows Server 2003 provides two regular RDP sessions (for Administrators), plus the ability to connect to the actual console session.  So, in effect, there are now three RDP sessions available for use at the same time.

Here at my client site, it seems that multiple people will jump onto a server and then not logoff when they are done.  The two "free" RDP sessions then become occupied, not allowing anyone else to connect.

But, by connecting to the Console Session itself, you can logoff one (or both) of the regular sessions using the Terminal Services Manager application (Administrative Tools program group), and then reconnect not using the "/console" switch to grab a regular session.  (That is, we try to reserve the use of the Console session for "emergencies").

Wednesday, May 16, 2007

Party with Palermo: Tech Ed Style

I'll be there!

June 3rd, 2007 @ 7PM - 11PM

Monday, May 14, 2007

VirtualPC Console Not Displaying

For the past several weeks, I've had a problem with VirtualPC.  Whenever I started the program, I would see it running in the taskbar, but the console itself would not show up on the screen.  Luckily, I could still start all of my VPC images using the context menu of the task item.

Today, I finally looked for a cause, and found it. 

VPC stored it's configuration in the following file:

%APPDATA%\Microsoft\Virtual PC\Options.xml

Within that XML file, I found the following node:


<height type="integer">246</height>
<left_position type="integer">4294935296</left_position>
<top_position type="integer">4294935296</top_position>
<visible type="boolean">true</visible>
<width type="integer">359</width>
<left_position type="integer">449</left_position>
<top_position type="integer">329</top_position>
<left_position type="integer">727</left_position>
<top_position type="integer">184</top_position>

Interesting to see the values that were being used for "left_position" and "top_position"... 

4,294,935,296 = 0xFFFF8300

Expressed as a 32-bit signed integer, this is the same as -32,000.  Doesn't tell me anything specific, but I found it interesting nonetheless.

Resetting these to 0 fixed the issue.

Monday, May 07, 2007

Day of .NET in Ann Arbor: RECAP

The Day of .NET in Ann Arbor 2007 Edition is over!  Like its predecessor last year, this event turned out to be very well received, and therefore, I think very successful.

The conference was again organized by three .NET user groups in this area: GANG, NWNUG, and AADND.  Specifically, the following people are who performed the day-to-day activities in bringing this event together:

  • John Hopkins (president of GANG): overall chairman of DoDN/AA 2007
  • Jason Follas (president of NWNUG): speaker/session coordinator
  • Darrell Hawley (program chair of AADND): registration coordinator
  • David Baldwin (AADND webmaster): sponsorship/public relations
  • Scott Zischerk (AADND): the DoDN webmaster (and T-Shirt designer)
  • Dave Redding (vice president of AADND): sponsorship
  • Chris Kotsis (secretary of GANG): sponsorship

The day of the event, we had some attendees who volunteered to help out with registration (and ended up missing the first session as a result).  Many thanks go to:

  • Dan Hounshell, Telligent
  • David Patow, Compuware

In all, we're pretty confident that there were actually 205 people in attendance!  This represents less than a 20% dropoff from our registration numbers.  For a free event like this, and for weather being as nice as it was, that is actually a great number (speaking from experience in having organized several events like this). 

However, we were anticipating a greater dropoff rate, and as a result, we ended up a little short on food at lunchtime.  Our sincere apologizes to anyone who might not have gotten any pizza, but we truly were trying to avoid last year's problem of having way too much food (which we even had a hard time trying to give it away to people passing by).  For full disclosure, we were anticipating the need to feed 180 people, not 205, to give you an idea of the challenge that we faced in trying to plan meals.

Another hiccup the day of the event was the fact that the campus facilities deactivated the air conditioning units in order to conserve energy (because WCC is in between semesters).  So, while there was airflow in the rooms, it wasn't necessarily "cool air".  The result was a very sauna-like experience while attending some of the sessions.  Let me just say that this very much took us by surprise as well!

We also considered people's feedback from the prior year, and tried to make little changes to improve on the experience this time around.  One thing that we tried hard to avoid was raffling off 100+ books during the closing.  So, we pre-selected book/software winners based on raffle tickets, and staged a giveaway in the hallway leading to the event. 

This actually worked well, but was not clearly communicated to all of the attendees as to how it worked (i.e., we didn't have enough books for everyone this year, so only the posted numbers were actual winners).  Also, we had unclaimed books when it came time to go into the closing session, so they were boxed up and left in the hallway in case someone came to us after the event to claim a winning prize.  To my surprise, all that was left afterwards were empty boxes, so even remaining valid winners were unable to claim their books.  I just hope that they went to good homes, and won't show up on eBay or Amazon.

Up to this point, I haven't heard anything negative about the Vendor Sessions that we inserted into the lineup.  I'm very much in agreement with the "Code Camp" mentality that our attendees shouldn't be over-marketed to by sponsors.  However, our sponsors are what make this level of event (which truly is a conference and not just a gathering of geeks who have nothing better to do) totally free to the attendees, so we have to show some love to them. 

In the past, I've often received inquiries from sponsors asking if they can have a breakout session to show off their products.  I've always had to deny such requests because I felt that sessions should be somewhat neutral in topic with concern to third-party products.  Otherwise, there might be a sense of mistrust by the attendees as to what the motives of the event organizers might be.

The Vendor Session, though, was the attempt to satisfy both worlds.  This was a dedicated timeslot where only vendors were presenting concurrently with one another.  The goal was to offer value-added sessions, and not just blind marketing, because session audiences would probably consist of current customers, or people who have already started researching the products.  These timeslots were also 1/2 the length of normal sessions, which helped to focus the presentations, and also helped to prevent boredom from developing in the audience.  More than anything else is the fact that there was no pretense involved: you knew going in that the content would be centered around a vendor's product.

The organizers will be having a post-mortem conference call tonight to discuss how we can improve upon this experience for next year's event.  If you happen to have any ideas, we would be glad to hear them!