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

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

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
  

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

Working on the SP2010 beta I bumped into an issue with search. I decided, after various attempts to fix it different ways, to rerun the Sharepoint 2010 Products Configuration Wizard. But when I did I ran into an error on Step #5 - namely a System.Security.Cryptography.CryptographicException of "Object Already Exists".

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.

Trying to run the SP 2010 Config Wizard to resolve a Search issue I ran into the problem shown below.



The resolution was that I was logged in with an account that was not used in the SQL database (remember you need the perms)...

If you try to create a Maintenance Plan on Sql 2008 you may get the following error:
'Agent XPs' component is turned off as part of the security configuration of this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure....

The reason is simple - the Sql Server Agent Service, which handles Maintenance plans among other things, is not started automatically. The service is set to Manual start. The solution is simple - just set it to Automatic (so it starts in case of a reboot) and start it up!

You can, of course, do this through windows services, but you can also do it through the Sql tools - specifically the "Sql Server Configuration Manager".

Step 1 - open up the Sql Server Configuration Manager and click on 'Sql Server Services in the left pane. You will see that the SQL Server Agetn is Stopped and has its 'Start Mode' set to Manual.

Step 2 - double click on the Sql Server Agent in the right tab and its properties will appear. Click on the 'Start' button to begin it running.

Step 3 - now click on the 'Service' tab and change the Start Mode to Automatic. This will ensure that if your server restarts this service will start as well (and hence you will get your Maintenance plans.

Now, give yourself a raise and take the rest of the day off....

There appears to be an issue with w08r2 when it comes to using Hyper-V. When attempting to launch your VM you might encounter the error: The application encountered an error while attempting to change the state of %yourVM%.

The solution seems very simple (thanks to this post) which is that you need to give 'Authenticated Users' the 'List folder / read data' permission at the root of the drive that contains the Virtual Machines (and you ONLY need to do it at that level, not the ones below).

Why this solves the problem I do not know, but here are the steps (with some pictures) to walk you through the process:

1 - Open up the root of the drive's properties and choose the Security tab. Click on the Advanced button

2. Click on 'Change Permissions'

3. Click on 'Add', Type in 'Authenticated Users' and hit the OK button, you should see the screen below. Change the "Apply to:" to be "This folder only" and put a check in to the "List folder / read data" check box. Click 'OK'

4. Make sure NOT to check the 'Replace all child objects...' checkbox. Check your settings, and click OK. Click OK to close the Properties screen for the drive and you should be good to go.