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...

My Windows Update service on one a w08r2 x64 box told me that I had an update.

So I checked and discovered that it was KB967723.

I ran the install but it failed with error code 80070490

After trying various solutions (such as turning off the Windows Update service and moving the log files) I finally manually downloaded the problematic file and installed it. No more problems. I don't know what was the issue - was it snagging the x86 version? was it getting the Vista one? Whatever triggered it, this resolved it.

Download Locations:

• x64 - http://www.microsoft.com/downloads/details.aspx?familyid=6E46822E-F79D-492D-AD01-EE680AD324F5&displaylang=en
  
• x86 - http://www.microsoft.com/downloads/details.aspx?familyid=35c1d5a9-a953-4fc6-90c0-d2358c7b89e6&displaylang=en
  

We recently had a case where a user moved a folder into another folder expecting that the permissions in the parent folder would automatically roll on down. Of course they did not, when you copy WITHIN a volume it maintains its original perms.

What was really interesting is what happened when we tried to use the ole 'Replace all child object permissions with inheritable permission from this object'. Although the user was copied down, the perms were not. The user DID NOT get the inherited perms on the sub objects.

You have to dig to find the correct checkbox.

• Open up the properties for the parent folder
• Selected "Advanced"
• Select "Change Permissions"
• Make sure "Replace all child object permissions with inheritable permissions from this object" is checked.
• Click on the user/group that you want to push the perms down for and select the "Edit" button
• Make sure that the "Apply these permissions to objects and/or containers within this container only IS CHECKED (note it is not checked in my image)
• Click 'OK' till you are done...

I am cross referencing this to Visual Studio 2008 since I first ran into this trying to connect to the remote website. I got yelled at:

When I looked I found that it had been installed and even approved to run:

So I right clicked on the Website, choose All Tasks, and Configure Server Extensions 2002

I got yelled at, AGAIN!

This looked a LOT more serious. But luckily some web browsing gave me an hint. What you did not see was that the Microsoft Sharepoint Adminstration site was stopped.

So I started it up, and voila!

I rebooted my clustered Hyper-V server. When I logged back on a test Virtual Server was showing a 'Saved-Critical' state. Attempting to start it resulted in the error message 'failed to restore virtual machine state'.

The issue? I had not made the VM clustered, so it was trying to launch the server without having access to the drive where the VM was stored. DOH!!!

Roll it back and start it, no problemo....

Recently someone reported that a banner ad they wanted posted on a page was not showing up internally, although it did when viewed from their home. The banner ad was a hyperlinked picture - snagged from an external site. What was happening internally was that the image simply did not appear, although the rest of the page rendered fine and the call to the remote site's page (wrapped in a javascript script tag) was in the page source.

When I tried to open the specific page I received a error status 64 - The specified network name is no longer available.

Suspecting that the blockage was caused by ISA, and also suspecting that the blockage might actually be a good thing, I loaded fiddler on a outside client and tried to access the page. Sure enough, fiddler (once again) came through. The issue? In the words of fiddler 'This buggy server did not return headers.'

The issue is that whoever was returning the code stripped out all headers. While browsers will let that pass, ISA will block it.

The solution? Fix those darn headers!!!!

Recently when playing around with the Sharepoint 2010 beta I extended a site to use Forms and passed that through ISA 2006.

This is all very basic stuff, there are a number of good references on how to set this up, but what I did not expect was the http 500 internal error on my browser (see below).

The solution was to modify the HTTP filter (egad! an error message that actually gives the correct problem!) within ISA for that Rule (right-click the rule and select "Configure HTTP") and uncheck "Verify normalization" (see image below). I do not know if this is restricted to Sharepoint, but I suspect that will all the razzle-dazzle that SP2010 is trying to pull off it is tripping over the big feet of ISA...

This was verified by checking the logs. I tried many, many things to resolve it, including making sure "Network Service" had full control over the 14-hive, per this blog and setting up Network Service using the aspnet_regiis -SampleKeys, etc. I even disabled the UAC (see my earlier post for an explanation).

No dice.

The resolution lay, as you may be suspecting, in messed up perms on the RSA folder, specifically C:\Program Data\Microsoft\Crypto\RSA\MachineKeys. I had checked to the RSA level and Administrators had full perms (I was logged on as with an Administrative account) but I had not taken the next step and checked MachineKeys.

Turns out that that folder had removed all perms from Adminstrators. I ended up having to take ownership of the folder and give Admins full perms again. Sure enough - it worked...

As a bonus it DID fix my Search problem (I was getting "The search request was unable to connect to the Search Service.").

Maybe.