If you want to use OWA webparts with Integrated Authentication or Basic and have it default to the user that is logged on, the steps are simple - leave the username blank (see below).

But if you have done that you may be surprised to find that it continually prompts you to log in on that page EVEN THOUGH YOU ARE ALREADY logged on.

Not putting in the info gives you a beautiful 401 error: 

Luckily the resolution is simple.

What you want is that you will be logged on to the mail server with the current user name and password. But if you open up the security settings on your browser you will find out that this is not the option.

There are two ways to resolve this - both involve changing the setting. You can either change the zone that it defaults to (ie make Local Intranet always do 'Automatic logon with current user name and password') or you can put the mail server in the Trusted Zones.

I like the latter.

Go into the Securities tab, click on 'Trusted Sites' icon and then click on the 'Sites' button.

Once you are in there you can add the FQDN of the mail server (since you will be using its cert)...

Voila!!! 

Note: if you want to do this on a larger scale I would suggest you turn to your handy-dandy Group Policy editor. You can find what you are looking for User Configuration / Windows Settings. I will leave the rest of the steps up to you...

I could not remote desktop to one of my servers so I actually had to get up and walk over to it.

Sheesh!

I had the firewall already happy, had Remote Desktop enabled. Luckily, the solution was fairly easy to fix. The server was part of a cluster and it had the network connection listed as Public, not Work. If this happens to you, simply open up the Network and Sharing Center, right click on the appropriate 'active network' and select Work.

My favorite bit in the description for Work network is "Don't choose this for public places such as coffee shops or airports." Hey, but what if I work there???

First off, I apologize for the lack of pictures. I find they make explanations easier. Unfortunately I resolved this months ago and so all my pictures have been mislaid...

Trying to push out KB 974417 a while back I noticed that certain machines were getting an error. A lot of research via the web uncovered that the issue lay in the fact that those machines had KB 976569 already installed. For some reason this later, not critical update (only important) was preventing KB 974417 from installing. This can happen when a machine is running a variety of updates and gets the order off.

The solution was fairly simple - you just needed to UNINSTALL KB 976569 and INSTALL 974417 and you would be fine. The problem is that you can not UNINSTALL KB 976569 via WSUS. You get a little notification that it can not be selected for uninstall. The probable reason is that it is part of a .net 2.0 update and other updates follow after. So you have to manually uninstall it, or some such.

One of the nice things about WSUS (and also a rather scary security question) is that it runs with higher privileges, which it needs to install the updates. As a result if you have locked users out from installing software willy-nilly (technical term) than you run into a problem when you try to uninstall in that you need to give them the same permissions.

Okay, let's start at the beginning - I won't bore you with all the different permutations I went through in determining my final process - I was writing code to wrap the uninstall in a security wrapper, etc, etc. I will take you to what I did and you can decide for yourself if this is how you want to do it.

• Note #1 - use MSIExec to uninstall the package. Critical note, you can not specify the package itself (since this is an update to .net) you need to specify the GUID of .net and then the GUID of the package itself. Like so:
  msiexec /package {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} /uninstall {621253FA-14E8-34AB-82B3-22590E6A961A} /passive
• Note #2 - I wrapped the MSIExec in a little C# program I used to bump up the perms - basically I used the ability of ProcessStartInfo to pass in a username and password (thanks to David Hayden's nice post on this). I will expand on that in another post if someone asks. I had the dickens of a time (another technical term) using Runas which might seem the more obvious way to go for you non-programmers, but never could get it to work. This was quick and dirty for me.
• Note #3 - I stuck the C# program (called RemoveKB976569.exe) out on Netlogon and used schtasks to remotely create a timed task to run on whatever remote computer I wanted to affect. Like so:
  schtasks /create /s \\<computername> /RU <adminUsername> /RP <adminPassword> /TN RemoveKB /TR <domainControllerNetlogonPath>\RemoveKB976569.exe /SC ONCE /ST <timeToRunTasks> /V1

Now, granted, you could touch every box if you wanted to. This was my attempt not to have to. Complicated, yes. Successful, yes.

Have fun...

I stumbled across this - http://deepakrangarajan.blogspot.com/2008/11/moving-system-databases-in-sql-server.html.

:)

If you have ever had to truncate a log in Sql 2005, the 'with truncate_only' is fairly familiar. Unfortunately for you, if you have it in your scripts, it has been removed in Sql 2008. 

You can use the Sql Management Studio to shrink the log files, I can post later about how to do this, but for some databases it will appear not to work (even if it throws no error). The log files stay the same size.

What may be the issue is that the Database is using a Full vs a Simple backup recovery method. You can find out more about the difference between the two here -> http://msdn.microsoft.com/en-us/library/ms187048.aspx. What we are concerned about is the note show below:

Note
Under the simple recovery model, the transaction log is automatically truncated to remove any inactive virtual log files. Truncation usually occurs after each checkpoint but can be delayed under some conditions. For more information, see Transaction Log Truncation.

What this means in the short run is that by switching your backup recovery method to Simple, you will instantly be able to shrink your log file.

Ex: Alter Database %your Db Name Here% Set Recovery Simple

I would be remiss if I did not mention this note from the page on the Simple recovery method:

Important
The simple recovery model is inappropriate for production systems for which loss of recent changes is unacceptable. In these cases, we recommend that you use the full recovery model. For more information, see Backup Under the Full Recovery Model.

One could always switch it to Simple, truncate, and switch back to Full, but it would probably be better to keep it at Full and establish a more functional means to keep those pesky log files small...

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!