Whilst trying to install the MS CRM 4.0 client on my laptop today I received the following error:
“Microsoft Outlook is not set as the default mail client. Please set Microsoft Outlook as the default mail client from Control Panel\Internet Options\Programs, and then re-run the check.”
Luckily this was fairly easy to diagnose with the help of the excellent Process Monitor utility. All I had to do was setup a filter to only capture events for the “Microsoft.Crm.Client.Config.exe” process by going to Filter->Filter and selecting Process Name is Microsoft.Crm.Client.exe as an inclusion filter. Then using the toolbar deselect the file events and run through the wizard again until I got an output like this:
Here we can see that the registry key [HKLM]\SOFTWARE\Wow6432Node\Clients\Mail\(Default) key is being interrogated, a quick look at this in Registry Editor shows that the default is “Windows Mail” for some reason as shown below:
All we need to do is change this value from “Windows Mail” to “Microsoft Outlook”:
Then the wizard will run through fine!
I am unsure if this is a Windows Server 2008 issue or a general x64 issue, however to resolve it change
from “Windows Mail” to “Microsoft Outlook”
I am unsure if the Wow6432 key is unique to my machine / configuration.
I’ve been trying to play around with System Center to see how we can use it to monitor our web application solution (DB utilisation, bandwidth, web server CPU/RAM etc).
Having eventually got through all the issues regarding the pre-existing WSUS 3.0 setup, existing SSRS install etc I got to the ‘installing’ section. This section took an absolute age to run (20mins approx on a Xeon 3050 (2×2.13Ghz) with 2Gb RAM). It would run through “Software Distribution and Update Management”, then “Server and Client Monitoring”, and finally “Reporting”. However on Reporting it would just put a red X next to it, then appear to roll-back a bit and reboot the PC without prompting – NICE!
I looked for a while and couldn’t find any information about it until I stumbled across KB937831 which basically describes a problem which applies to our environment. Basically our domain is setup as follows:
Our company is called Xyz Ltd
Our public facing domain name is xyz.com
Our NETBIOS domain name is XYZ
Our Active Directory FQDN is internal.xyz.com
The issue appears to be that the installer makes an assumption that the first part of the FQDN is the NETBIOS name, which for us it isn’t. In this case it’s authenticating with the username INTERNAL\Administrator rather than XYZ\Administrator. The relevant part from the %TEMP%\ SCEReporting0.log file is:
UnableToGetUserNameFromManagementServerActionAccount = SetPropertiesToManagementServerActionAndSDKAccountCA error: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessMonitoringException : The specified domain does not exist or cannot be contacted.
UnableToGetUserNameFromManagementServerSDKAccount = SetPropertiesToManagementServerActionAndSDKAccountCA error: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessMonitoringException : The specified domain does not exist or cannot be contacted.
The KB937831 says that the patch is only available via product support, however this isn’t true as it’s included in the roll-up available in KB943111.
UPDATE: it seems I was a bit premature, that roll-up doesn’t resolve the issue. There appear to be two relevant blog posts which point to how to get the HotFix via a web request form, I’m waiting my 8hours now…
We’ve recently integrated the Virtual Earth service in to our on-line application. However, we’ve had some issues when clicking on “3D” the installer kicks off and then you get a helpful error message:
Virtual Earth 3D Installer
Installation failed, check the log file for more information.
We have an authenticated proxy server which it appears the installer doesn’t cope with particularly well. After much hunting it appears that the ‘log file’ is in fact %TEMP%\InstallLog.txt
The key part appears to be:
[2007/09/11 18:53:01.180] DownloadManager: Queued 'http://go.microsoft.com/fwlink/?LinkId=93683' for download to 'C:\Program Files\Virtual Earth 3D\VirtualEarth3D.msi'...
[2007/09/11 18:53:01.180] DownloadManager: Beginning data download for 'http://go.microsoft.com/fwlink/?LinkId=93683' to 'C:\Program Files\Virtual Earth 3D\VirtualEarth3D.msi'
[2007/09/11 18:53:01.196] DownloadManager: Download complete for 'http://go.microsoft.com/fwlink/?LinkId=93683' to 'C:\Program Files\Virtual Earth 3D\VirtualEarth3D.msi'
[2007/09/11 18:53:01.196] SystemState: Checking the installation state for Virtual Earth 3D.
[2007/09/11 18:53:01.211] InstallManager: Queueing MSI install of 'C:\Program Files\Virtual Earth 3D\VirtualEarth3D.msi' with paramaters ''...
Looking in the Virtual Earth 3D directory the VirtualEarth3D.msi file is just 4kb. Thus, all you need to do is download and install the msi directly from http://go.microsoft.com/fwlink/?LinkId=93683
I’m not sure if Microsoft will retain the hyperlink when they release a newer version of the 3D client, thus you may need to check your installer log for a newer link.
I’ve just installed WSUS 3.0 on a new server and decommissioned WSUS 2.0 on our old server. On our 2.0 server I had both WSUS and Sharepoint installed which presented me with a few issues when I tried to upgrade it to 3.0.
For this reason I chose to install WSUS 3.0 on the alternative port of 8530, leaving port 80 for other uses:
However having set the Group Policy to simply http://mercury for both settings and waiting a day, no clients were registered. I trawled through all of the documentation and there was no reference to doing anything different if WSUS was not on port 80. You’ll notice from the IIS setup that it did indeed create virtual directories on the port 80 web implying that this should work.
Well, here’s the answer, YOU HAVE TO SET THE PORT NUMBER on the URL, this would also apply if you were directly fiddling with the settings in the registry at:
An error occurred on a query to database **YourDB**
V-79-57344-33938 – Write on “**YourDB**_00__7091c250_56c1_4f5e_9bf8_3eced26e1926_” failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)
We’ve been getting this error backing up our main SQL Server 2005 (SP1) database which has Full recovery mode with a 4GB data file and 35Gb transaction log. Searched about a bit and found various articles referring to the the VDI and guessed it was due to SQL Server not being able to put the temporary backup file to disk – I was write.
Basically ensure that there’s sufficient space on %TEMP% to hold it!
We had ours set to a partition with just 20Gb space – I had %TEMP% set to a couple of 15k rpm 36Gb SCSI disks.
We’ve been having some issues with Outlook 2007 slowing down to a complete crawl on several of our [development] machines. All are running XP Pro fully patched up and are connected to Exchange 2003.
On my PC I find that quite often the new e-mail window can’t keep up with the rate I’m typing, often I get a whole sentence ahead of it before I see anything on the screen.
We’ve all noticed that Outlook 2007 seems to be a bit of a hangle-hog using anywhere between 9,000 and 14,000 handles with no particular pattern to it. You’ll notice my PC runs the MS CRM plugin, however we see similar behaviour on machines not running with that plugin installed.
Any ideas greatly appreciated!