Blank page (auth.owa Http 500) when logging into Outlook Web Access running on Exchange 2010

Recently had to restart a client’s server after running some Windows Updates. A few hours after the restart the client contacted me stating that they couldn’t access their e-mails via the web.  I quickly had a look, the login page presented itself, so I logged in and after clicking Sign in I was presented with a blank page pointing to auth.owa.  This was a little puzzling as there were no updates for Exchange so why did it break?  Checking the IIS logs, I found that the error was 500 which indicated some kind of authentication error.

A little powershell cmdlet you can run is Test-OWAConnectivity. So I ran the cmdlet and recieved WARNING: An unknown failure occurred during logon. So I checked IIS and ensured that all of the authentication was set correctly and indeed it was.  So after some poking around on the web I found out Exchange 2010 palms off the Forms Based Authentication to a seperate Service called  Microsoft Exchange Forms-Based Authentication Service. Starting this service fixed the blank page issue and allowed clients to authenticate correctly.

How to Switch from IDE to AHCI without repairing/reinstalling Windows

A few weeks ago I installed an SSD drive in my home PC. For some reason up until tonight I never checked what the Sata mode was set to in the bios. It was set to IDE. Usually when changing the storage mode in the bios requires a reformat as windows will no longer boot. So I looked around the internet and found some really great instruction to switch from IDE to AHCI without having to repair or reinstall windows. Thought I might share it.

You start with step 1 while you are still in windows in IDE mode.

  1. Run the Registry Editor (regedit.exe)
  2. Navigate to Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci
  3. Set the “Start” value to 0 (zero)
  4. Navigate to Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Pciide
  5. Set the “Start” value to 0 (zero)
  6. Shut down
  7. Start up again, but before Windows boots go into the BIOS configuration screens and change the disk mode to “AHCI”. Save the new BIOS configuration and restart so that Windows boots.

When Windows starts, it will detect the change, load new disk drivers, and do one more reboot to start up with them. A quick little post, more to come.

Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: “The name on the security certificate is invalid or does not match the name of the site”

I recently setup a SBS 2011 server for one of my clients. For several reasons we changed the external name to reach the server so instead of remote.fdqn.com.au it would be exchange.fqdn.com.au this worked perfectly once DNS settings propagated and allowed employees to connect externally via webmail or Outlook Anywhere (one of the best features in exchange/outlook hands down).  One issue which popped up after we installed the certificate for this new domain is that it was assigned to a different domain than what was configured in Exchange 2010, so internally clients would get security pop-ups everytime they would open their outlook.

The fix requires the use of the Exchange PowerShell Console, so fire it up. Once it loads, we first need to know what the name of our client access server is (for sites with multiple CAS servers you need to use this on the server doing your auto-discovery). So run Get-ClientAccessServer which will list all of the available CAS servers, for this instance it is SBSSERVER. So now that we have a list of servers and we know which is doing the auto-discovery we need to re-configure it to the new DNS entry.  Microsoft documentation doesn’t have ” ” quotation marks but it is important to have. So now run Set-ClientAccessServer with the following
Set-ClientAccessServer -Identity "SBSSERVER" -AutoDiscoverServiceInternalUri "https://exchange.fqdn.com.au/autodiscover/autodiscover.xml" with SBSSERVER being your CAS server and fqdn.com.au being the correct domain the certificate is assigned to.

Once the command runs successfully, re-open outlook and you will no longer be presented with a security warning everytime you are on the internal network.

Changing the Registered User Details for Visual Studio 2010

One of the anoyances I’ve had when installing Visual Studio 2010 is the removal of the user information bit when accepting the License Agreement, this was useful but is now automated and the installer retrieves details from Windows itself.

After a fresh install of Windows 7 (with SP1 and it still needed updates afterwards) I installed my usual things along with Visual Studio, and thought now, how do I change the registered user details that show up in the about box, splash screen and are used as default values in the version resource. After having a quick poke around in the registry, I found the two areas that Visual Studio looks at. For a 64-bit machine they are the following two keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Registration\UserName
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

For 32-bit machines:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Registration\UserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

Changing these two will fix your about box, but what about that splash screen. Well running devenv.exe /setup with admin rights will cause Visual Studio to retrieve these registry settings and then make them appear in your splash screen. Making the circle complete which is what we set out todo. Hope that helps.

Fixing Error 1935. An error occurred during the installation of assembly errors.

Sometimes when installing software, I get an error during the installation of either the .Net framework or the Visual C Runtimes. This error, Error 1934. An error occurred during the instllation of assembly … will prevent the installation from being successfull, furthurmore after many hours of searching, many of the fixes listed around the web do not work.

To succsesfully allow the software installation to complete, a registry edit must be made. So go an open up Regedit and navigate to the following key: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control double-click on the RegistrySizeLimit and edit the DWORD value. In Hexadecimal enter FFFFFFFF or alternatively enter 4294967295 as the decimal value.

Once the registry change is done, restart the machine and then you can start the setup again that was causing you the issues earlier.

An optional set you can do once you have restarted the machine is to open up a command prompt window and type in the following command: SFC /SCANNOW this begins a windows file integrity checker ensuring that all windows system files are genuine and have not been edited or replaced, if you are running Windows XP you will need your installation CD to complete the scan.

Just about every encounter I’ve had with this error the RegistrySizeLimit has fixed the issue.

Exchange Management with AD Users when using RSAT for Windows 7

One of the little things with the have annoyed me since I’ve started using the RSAT tools in Windows is the fact that there is no easy way to manage Exchange. Sure I can install the Exchange Management Pack and use that, but like most admin’s AD Users and Computers is open just about all the time.

First thing you will want to do is go and download the Exchange System Manager for Windows Vista (located here). Once downloaded, extract the .exe file so that you have an ESMVISTA.MSI file. Now that’s extracted, open up a command prompt window and move to the location that ESMVISTA lives. Type in the following:

ESMVISTA.MSI /Q

With that command line the message is surpressed and the installation continues without any issues under Windows 7. This will only work for Windows 7 32-Bit and I have not found a way to get it working with 64-bit.

After a few minutes you will be able to open up AD Users and computers, right click and you will have the extra Exchange Tabs (pictured right), making Administration a little easier.

Fixing the Outlook Web Access web application failed to initialize error

During the Christmas break many still wish to check their e-mails whilst enjoying their holidays.  One of my Clients who don’t use OWA are now taking the plunge and going to be checking their e-mail (great feature). With SBS 2008 (so Exchange 2007), OWA is enabled by default, so I thought there would be nothing that I needed to do, I was wrong.

After loading up OWA on the server and my laptop I received the following error:

The Outlook Web Access web application failed to initialize.
..
Exception
Exception type: Microsoft.Exchange.Clients.Owa.Core.OwaThemeManagerInitializationException

The fix I’ve worked out for this is to copy the original files in the theme directory from your installation media (x:\Setup\ServerRoles\ClientAccess\owa\version\) back into the OWA working directory.

The cause, I suspect a corrupt file, not too sure exactly and didn’t have much time to investigate seeing as it’s holiday time, but believe something had changed the theme configuration causing OWA to look elsewhere for theme files, I also have a suspicion that an update might have caused this, but can’t confirm.

Moving your SUSDB when it is running under MSDE

During my morning rounds of looking after clients’ servers, running SBS 2008. I noticed one was running out of space.  It had recently been updated to WSUS 3.0 SP2, after doing a quick hard drive space check I found that SUSDB was over five gigabytes in size. Generally this database should be around one gig.  Until I had some time to investigate I thought the best thing to do was to move it to another hard drive, easier said than done.

Just a little tip, if you are running under Windows SBS 2008 then you will need to Run as Administratorwill need to run the Management Studio as an Administrative user by right clicking and selecting “Run as Administrator”. This will allow you to connect to the Internal Database as your SBS Admin user doesn’t have permission to do so.

Once the logon screen appears, your first thought would be to simply select the Microsoft##SSEE instance seeing as that is what the internal database is called but it still won’t connect. You need to connect via named pipes. Do so by typing the following into the server name field:
\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
Once connected you should be able to SUSDB under the Databases list.  To move the database is quite simple, we will detach, move the database files and then re-attach the database. Best to stop the Update Services Service before continuing (via the Services Snap-In).

Detach Database DialogOnce in Management Studio, expand Databases and right click on the SUSDB database. From there click on Tasks and select ‘Detach…’ a dialog window will pop up. We will want to ensure that SQL Server drops any connections to the database to ensure a successful detachment of the database, so tick ‘Drop Connections’. Once the process is complete, minimise the Management Studio and navigate to the databases location (usually under ‘c:\wsus\SUSDB’) and move the folder to a location with more space.

Once that is done, we can re-attach the database. Maximise the Management Studio and right click on Databases and select ‘Attach…’. From here you are presented with another dialog box, click on the Add button and select the new location of the SUSDB that we just moved. Once you have selected the database simply click on Ok and SQL Server will do the rest.

Start the Update Services service and WSUS should be fine and work just as it was before the move.

Office 2010 and Windows Sysprep Adventures

For our new roll out next year, we are deploying Microsoft Office 2010 and using KMS as our licensing method. Througthe use of sysprep’s generalize command, Windows will flush its Activation Status and associated hardware ID as well as rearming the activation state to its fresh install state (grace period).

With the introduction of Office 2010 brings improved piracy protection.  On our test deployment we found that our KMS Client count for Office 2010 wasn’t increasing and therefore wouldn’t reach the required count of 5 for activation, what was going on!  After a little bit of digging and the use of the Office 2010 Software Protection VB Script (ospp.vbs under the Office14 folder) we were able to see that the five of our test machines had the same CMID, therefore KMS thought that each was the same client. After a quick look through Technet we found out the issue.  When you run an Office Product it would automatically attempt to activate via KMS. Our Office installer also had its own activate upon installation command as well.

The fix for this issue and getting the count to increase (and finally activate) was to run a re-arm utility provided under program files (or program files x86, depending on your installed flavor):OSPP with DCMID

C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe

Running the utility under an elevated command prompt will then show completed successfully. If you wish to double check you can then run ospp.vbs with the /dcmid switch and find that there is now no Client Machine ID.

Once this is compelte, run your sysprep as you would and you will find that for each client that you activate from now on for your KMS will increase your count.  You will also find that if you have some clients with the same ID then they will also all activate.

I plan on having some other articles covering articles regarding Windows 7 sysprep so stay tuned.

Remotely enable Remote Desktop to connect to a remote PC

Occasionally you need to get something done on a remote computer (or a clients computer) but the computer doesn’t have an easy way for you to connect to it. Luckily, if you have admin rights to the remote computer, you can still connect without needing to turn on remote desktop before hand. To do that you will just need to download a little tool called PsExec (Available here). PsExec is a Microsoft tool part of their PsTools, the beauty of it is that it is portable and can be run from anywhere.

Once you have PsExec download you just need to open a command prompt and browse to the folder with psexec.exe. Once the command prompt is open, type in this command and it will enable remote desktop on the machine you specify.

psexec \\machinename reg add “hklm\system\currentcontrolset\control\terminal server” /f /v fDenyTSConnections /t REG_DWORD /d 0

Make sure you replace “machinename” with the computer you are trying to control remotely. Once this command has run you should now be able to connect with the Remote Desktop client (mstsc.exe) to the remote computer.