Archive for December, 2009

Update Rollup 8 for Microsoft Dynamics CRM 4.0

December 17, 2009

The Microsoft Dynamics CRM Sustained Engineering team will release Microsoft Dynamics CRM 4.0 Update Rollup 8 on Thursday, December 17, 2009.

Once the release is available the links below will take you to the necessary information about Update Rollup 8.

General Details about Update Rollup 8

  • Update Rollup 8 is cumulative. However, the Update Rollup 8 CRM Client and Data Migration Client packages require Update Rollup 7 to be installed. For all other CRM components you do not need to install any previous Update Rollups prior to Update Rollup 8
  • The Update Rollup 8 download contains updates for the 40 supported Language Packs. Prior to installing the Update Rollup 8 Language pack you must install the original Language pack.
    • If you have Language Packs installed, you should
  1.  
    1. Download the Update Rollup 8 Language Pack
    2. Install the Update Rollup 8 Language Pack
    3. De-provision the Language Pack
    4. Re-provision the Language Pack
  • Information about how to avoid reboots when installing the CRM Outlook Client can be found in the Update Rollup 4 blog posting.
  • The Update Rollup 8 Client can be deployed before the server is upgraded to Update Rollup 8.
  • Steps to make the Update Rollup 8 Client available via AutoUpdate can be found in the Update Rollup 4 blog posting. The Link and Patch IDs can be found in kb article 975995.

Microsoft Dynamics CRM E-mail Router

Update Rollup 8 adds support for Exchange 2010. However, the Update Rollup 8 Rule Deployment Wizard does not yet support Exchange 2010. We are working to add that support in future Update Rollups.

Advertisements

StarWind Free iSCSI Target

December 11, 2009

StarWind Free version is a free iSCSI Target that converts any Windows server into a block-level storage server or a SAN in less than 10 minutes.  This is a fully functional product at no cost. 

  •  Large 2 TB storage capacity
  •  Virtualization environment support for VMware, Microsoft Hyper-V and XenServer
  •  Enhances VMware environments by enabling VMotion, VMware HA, DRS and VCB
  •  Supports Windows server clustering for any application including SQL Server, Exchange, SharePoint

Download StarWind Free

Configuring the SharePoint 3.0 RSS Reader to use a Proxy Server

December 9, 2009

I was setting up an instance of Microsoft Office SharePoint Server 2007 (MOSS) on my customers’ Intranet and I was adding an RSS Reader web-part. I configured this web part to pull the feed from an external Internet site, and the web-part couldn’t read it. I tried pulling from a feed elsewhere on the Intranet, and it worked fine. Why couldn’t the web part see outside? Then I remembered  – the customer uses a Proxy server on their intranet. So I needed to configure SharePoint to use a proxy server.

How?

Turns out that SharePoint doesn’t have a setting for this as it just uses a setting embedded in the .NET Framework itself. This setting is configured in a file called “web.config”, located on my machine in the following directory:

C:\Inetpub\wwwroot\wss\VirtualDirectories\80

I found the one I wanted by opening the Computer Management applet in Control Panel, then under Applications and Services > Internet Information Server > Web Sites > SharePoint (80) and doing a “Browse”. The last name (“SharePoint (80)”) might vary for you depending on how you’ve configure you SharePoint installation.

Once I located and opened the web.config of the SharePoint site I wanted to put the RSS Reader applet into, I added this at the very end of the file ( inside the last tag (</configuration>)):

  <system.net>
      <defaultProxy>
         <proxy usesystemdefault = "false" proxyaddress="http://proxyservername/" bypassonlocal="true" />
      </defaultProxy>
   </system.net> 

Obviously, “proxyservername” is whatever the fully qualified name of the Proxy Server on the local network is. You can also append a port if required, e.g. http://proxyservername:8081/.

And that’s it! You don’t even need to restart anything, as IIS will automatically spot the change to web.config and automatically restart the relevant SharePoint site and incorporate the changes (so make sure there are no users on your SharePoint site in the middle of something when you make this change!)

If you have many sites on your SharePoint site, instead of changing every web.config you could instead change the machine.config once, located at %runtime install path%\Config directory, which on my machine was in C:\WINDOWS\Microsoft.Net\Framework\v2.0.50727\CONFIG. Just insert the code above at then end, inside the last tag (</configuration>). You need to reboot for this change to take effect, however but at least you only need to do it once.

One other thing to bear in mind is the security requirements of the proxy server (and my thanks to Selar for pointing this out) as MOSS has some limitations in this regard. You need to configure the proxy server to allow IP authentication from the Web Front End(s), as MOSS is incapable of passing NTLM credentials to the proxy server. There needs to be a rule on the proxy server allowing http and https requests from the IP address(s) of the web front ends but it should not require any credentials be passed along for these requests.

Change the SharePoint ULS Log File Path From a Script

December 4, 2009

PowerShell script that will move the SharePoint log files and set the retention of the log files.

To run this script you will need to set the PowerShell execution policy using the following PowerShell command:

set-executionpolicy Unrestricted

Copy the following code and paste it into a PowerShell script file like SetSPLog.ps1. To call this from the command line or within a command script file use the following syntax:

This will move the log files to D:\Logs\SharePoint, keeping 96 files that have 30 minutes of logs in each file.

powershell.exe “& .\SetSPLog.ps1 ‘D:\Logs\SharePoint’ 96 30”

PowerShell Code (SetSPLog.ps1)

if ($args.length -lt 3) {write-warning "Syntax: SetSPLog.ps1 [Location]
[Logs to Keep] [Log Interval]"; break} [System.Reflection.Assembly]::
LoadWithPartialName("Microsoft.SharePoint")
$diaglog=[Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local
$diaglog.LogLocation=$args[0]
$diaglog.LogsToKeep=$args[1]
$diaglog.LogCutInterval=$args[2]
$diaglog.Update()

Microsoft Dynamics CRM 4.0 Data connector

December 3, 2009

Microsoft Dynamics CRM handles all the reports with Microsoft SQL Server Reporting Services (SRS). SRS is a separate application that you can install on a different server than SQL Server or the Microsoft Dynamics CRM Server if desired. Microsoft Dynamics CRM then connects to SRS by using the Reporting Services URL, as specified during installation.

When is Data connector used?

The Connector for Microsoft SQL SRS is not required during a normal, non-IFD installation. For IFD installations, or when you make modifications to the default setup, Data connector installation is mandatory for running the reports.

Data connector is also required when the scheduling reports are used in CRM.

What does Data Connector do?

Previous versions of Microsoft Dynamics CRM had a common problem with CRM and SRS communication, referred to as the double-hop Kerberos authentication. When both were installed on different servers it was required that we enable delegation in order to pass the authentication token to SSRS.

In CRM 4.0, we did away with the requirement for delegation to be configured by introducing the component called the SQL Reporting Services Data Connector. It’s basically a data processing extension which attaches itself to the SSRS server and accepts the auth information from the CRM server and passes it to the SSRS server. This resolves a common authentication problem when trying to access and run reports in previous versions of Microsoft CRM, referred to as “The Kerberos double-hop authentication issue.”

A common issue while installing CRM data connector

The above error/warning is caused because of the following conditions:

Condition 1 – Error
 
A Microsoft Dynamics CRM server is installed on the computer where CRM connector is being installed
The CRM server is running under the same account as the Report server application pool

Condition 2 – Warning

All CRM components: SQL, SRS are installed on a computer that is running Microsoft Server Small business edition where Connector is being installed

What happens behind the scenes?

The reason you are encountering this error is because of a security issue that can occur if the CRMAppPool and the application pool used by SRS are the same account. While communicating to the SQL server.

When using the CRM Data Connector, it authenticates from SRS to SQL as the SRS Application Pool Identity and CRM grants the SRS app pool account the CRMReaderRole, which grants select permissions to the filtered views. When CRM is installed, the CRMAppPool identity is granted dbo permissions to the database. If both accounts are the same, the account used for the CRM Data Connector would have full database access.

Therefore to help make the data more secure, before you install CRM 4.0 connector, you can either:

a) Install CRM and SQL reporting services on different machines

b) Configure Reporting services App pool on the computer to user a different account.

“The path is not of a legal form” while installing the Dynamics CRM Outlook client

December 2, 2009

Recently, I was installing the Dynamics CRM 4.0 Outlook client on a test server.  After selecting the install directory, I received an error message saying “The path is not of a legal form”.

However, the specified folder was “C:\Program Files\CRM Client” and it was present on the C drive. After a few searches on the Web, I found someone having a similar issue while installing the CRM Data Migration Manager.Their solution was to update manually the registry.

Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Installer\UserData\S-1-5-18\Products\59DD8CB00184F24E99A62CF4D6109FA\InstallProperties]

Name: InstallLocation

Set the Data value to “C:\Program Files\Microsoft Dynamics CRM”

After this modification, setup continued without an error.

On My server (italian language) the installation key of Microsoft Dynamics CRM Server is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Installer\UserData\S-1-5-18\Products\43689CC1EAEE14C458FDAD0580BC0C97\InstallProperties]

Setting the value [InstallLocation] to “C:\Program Files\Microsoft Dynamics CRM” the setup continued.

In another case (english language) the installation key of Microsoft Dynamics CRM Server was:

059DD8CB00184F24E99A62CF4D6109FA