Due to the number of updates on this issue, I have included them at the top... below is them is the original blog...

Update: MSoft has written a vbs script to do the same as what I have listed below. The main difference is that you do not need to hunt through pending.xml - look at http://support.microsoft.com/kb/975484 for more info.

Update: MSoft has redone how WSUS rolls out w07sp1 - "Packages have been updated to address a known issue." http://support.microsoft.com/kb/894199 which might help this issue. Note that this does not appear to be a change in sp1, but in the wsus rollout format...

Update: MSoft has released Remote Adminsitration Tools that work with SP1 -> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Further Notes on issues with w07 sp1 in general: http://www.infoworld.com/t/microsoft-windows/what-you-need-know-about-windows-7-service-pack-1-699

Fur

Recently rolled out SP1 to our wee test group on WSUS. While it worked for most, one machine simply refused to boot, giving the BSOD (black screen of death) with "Fatal Error C0000034" as witnessed below...

Before I lay out what worked for us, let me give credit where credit is due - specifically to "thewoot" -> you can see his post here. He also mentions that you can send him money via paypal if you want to say thank you in a practical way - considering the potential costs to your organization I don't think that is a bad idea at all...

Here are his steps (with some notes of changes...)

1 - Reboot your computer with the Windows 7 disc in the drive

2 - Select "Launch Startup Repair"

3 - !!! Cancel the "repair"

4 - Click on "Don't Send" (if they don't know by now...)

5 - !!!! Click on the link "View advanced options for recovery and support"

6 - Click on the "Command Prompt" link at the bottom.

7a - fyi - if you need to get files off (just in case) you can put in a USB drive and start transferring files to it. You can either use the command prompt, or the File/Open dialog of Notepad to move the files...

8 - You are going to be looking for the pending.xml file for the installation. Please note that it might be on D: not C: because of the System partition that Windows 7 sets aside. DO NOT FREAK OUT IF YOU GO TO C:\ AND THERE IS NO WINDOWS, GO TO D: IN THIS CASE

9 - Use File/Open to browse to (either C: or D:, see above) and \windows\winsxs\. Make sure to have "All Files(*.*)" selected in the bottom right so that you can see the xml files.

10 - Make a copy of pending.xml by dragging it down in the file/open screen (just because we are paranoid)

11 - Open up pending.xml. This will take a LONG time because it is a LARGE file. Just be grateful Notepad can handle it.

12 - Do a search for 000000000000.cdf-ms. This is the section you are going to remove.

13 - Delete the section that includes it. In thewoot's directions he has you start with the <Checkpoint/> file BEFORE it and continue through to the end of the section that contains it, as he points out, the text may vary slightly... This will take a while (big file)...

<Checkpoint/>

<DeleteFile path="\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"/>

<MoveFile source="\SystemRoot\WinSxS\Temp\PendingRenames\e56db1db48d4cb0199440000b01de419._0000000000000000.cdf-ms" destination="\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"/>

14 - SAVE THE PREVIEW.XML FILE!!! This will take a while (big file)...

15 - Close notepad

16 - Exit the command prompt (type 'exit' or just close).

17 - Select Restart...

16 - It may take a bit to boot up. In our case the install 'failed' (woohoo!!!) but in other cases it might claim to 'succeed' whatever that means at this point...

So what does this all mean? I know that it is instinctual to blame MSoft, but I suspect this has to do with a 3rd party changing files. I say this because this installed fine on a number of boxes but failed on someone who does graphic design. It is quite simply impossible for MSoft to test all the various scenarios that exist in the entire world, so I am giving them some slack. As long as they fix it quickly!

What are the takeaways that I get out of it?

1. ALWAYS testbed your updates. This is a no-brainer, or should be, but sometimes admins tend to assume that simple because it works 99% of the time it will work 100% and this simply is not true. I know there is a LOT of other stuff to do, but do not blame MSoft because they cannot test EVERY SINGLE situation.
   
2. The larger the update the more testing. I installed this on a couple of boxes BEFORE I rolled it out to my testbed. Then I waited a bit. Because I was so careful I only had to repair one computer rather than who knows how many...
3. Have a beer... there are far greater catastrophes happening even as you read this, be grateful that this is not one of them...

Recently a client tried to use a program I wrote years ago on their new 64-bit Windows 7 box. It popped up the error "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine." After some quick digging I discovered that the issue is that issue is that the 64-bit version of windows does not like the 32-bit version of the Jet Database...

My solution was to simply repackage the product to have the Platform Target be x86 (see image below) in the properties for the program. This allowed it to run on Windows 7 with no error.

Please note that if there are other things that can trigger this - esp running an app in IIS - look at http://blog.nkadesign.com/2008/windows-2008-the-microsoftjetoledb40-provider-is-not-registered-on-the-local-machine/ if this is not the issue...

Happy coding...

Updating a program of mine I noted that when I called the PrintDialog and passed it my PrintDocument (or variant thereof), I did not get any said PrintDialog.

Long story short - you just set the UseEXDialog to true:

PrintDialog _printDialog = new PrintDialog();
_printDialog.UseEXDialog = true;

See http://msdn.microsoft.com/en-us/library/system.windows.forms.printdialog.useexdialog.aspx for more info

While trying to map a drive to an older server in w07 it informed me that the network password was wrong, even though I KNEW it was correct.

After a lot of hunt and peck I came across the issue - basically by default it refuses to transmit the login except in the highest format (NTLM v2). Which makes sense, and is undoubtedly documented somewhere. EXCEPT IN THE ERROR THAT IS RETURNED! I mean it might at least give a hint rather than just rejecting the password.

Solution (demonstrated just on a local box but this can also be done via a domain Group Policy): go into your Local Security Policy.

Go into Security Settings/Local Policies/Security Options and go down to "Network Security: Lan Manager authentication level"

Set it to "Send LM & NTLM - use NTLMv2 session security if negotiated". This will give you backward compatibility.

Of course, the real solution is to move everything to NTLMv2...

I was pondering the UAC (User Access Control) on Windows Server 2008 and Windows 7 (nobody talks about Vista anymore) and it occurred to me that the experience of interacting with it reminded me of another time. An annoying, apparently helpful attempt by Msoft that actually prevents you from doing work (see here). Suddenly it struck me - the return of 'Clippy'!!!

Now, first off, I can understand MSoft's implementing the UAC. After all, everyone knows that MSoft is so full of holes that it should if it were a cheese it would be swiss cheese. Everyone knows that, even if it is not necessarily true. So to convince everyone that they were secure they had to prevent users (that would be us) from doing stupid things. Like installing programs that should not be installed or changing setting that would render their computer unbootable. Because, of course, if a user does those things than the people REALLY at fault are not the users (heaven forfend) but MSoft!

To quote on of my favorite sayings - "calling something foolproof fails to take into account the ingenuity of fools."

They have to do this because we are so stupid as a race that an entire industry has sprung up to inform us of the obvious. Such as "do not put a gasoline can in a fire" or "ax blades are sharp" or (as in this picture) "this egg product contains eggs".

Still, there has to be some sort of happy medium. W08 only offers two options - on or off. W08R2 offers more (and I will make some notes on that in another blog) but I fear that in general MSoft has gone too far in the wrong direction. They are so concerned with protecting us that they are annoying us. And if something becomes annoying we generally stop doing it.

Goodbye Clippy. Goodbye UAC.

Do I have a solution? Of course not. Except to suggest that the UAC could be tweaked to be more specific. What I mean by that is simply that rather than trying to prevent you from doing EVERYTHING, it should only prevent the main crucial things. Perhaps it should not question you when you are installing programs but only when you are not installing them from an executable from a DVD or from your local drive.

Or perhaps the solution is that high-end users simply turn 'Clippy' off. He is annoying and YES I DO KNOW WHAT I AM DOING AND I WANT TO DO THAT!

At least, most of the time...