Replace this with the title of your post

When adding users to CRM via the Add Muliple Users tool, it's possible to view all users in Active Directory and then add them as CRM users

In a hosted environment, this is not ideal as admin users for each organisation will be able to see users from all other hosted customers.

With CRM 4, there was a method of restricting users to only browse users in a particular business unit (see here). Unfortunately, this tool does not work with CRM 2011.

By looking at an old CRM 4 instance, I had a hunt around to see which settings were changed by the config tool to see if they would still work in CRM 2011. Thankfully, I found where to add the settings and it still appears to work in CRM 2011.

Note: The rest of this post involves making changes directly to the MSCRM_CONFIG database and this is completely unsupported. Please only try this if you have your CRM databases backed up.

I've created the script below which enters the OU settings into the MSCRM_CONFIG database, just as the tool for CRM 4 used to.

You'll need the unique name of your organisation (you can get this from settings\customizations\developer resources).

You'll also need the LDAP path of the Active Directory OU which contains the users for the organisation.

Mine was quite basic, so the OU is in the root of my AD forest.

Put the 2 settings into the settings section of the SQL script and then run it against your MSCRM_CONFIG database.

[code lang='sql']

DECLARE @crmOrg nvarchar(max), @crmId Uniqueidentifier, @ou nvarchar(max), @exists uniqueidentifier

--##ENTER SETTINGS HERE

--##This is the unique name of the organisation

SET @crmOrg = 'YourOrgUniqueName'

--##This is the LDAP path to the Active Directory OU containing the users for the organisation

SET @ou = 'LDAP://dev.dom/OU=TestOU;DC=dev;DC=dom'

--##ENTER SETTINGS HERE


SET @crmId = (SELECT [ID] FROM [MSCRM_CONFIG].[dbo].[Organization] WHERE UniqueName = @crmOrg)

SET @exists = (select [ID] from [MSCRM_CONFIG].[dbo].[OrganizationProperties] where [ID]=@crmId and [ColumnName] = 'UserRootPath')


IF(@exists is null)

BEGIN

INSERT INTO [MSCRM_CONFIG].[dbo].[OrganizationProperties]

([id], [columnname], [nvarcharcolumn], [encrypted])

VALUES (@crmId, N'UserRootPath', @ou, 0)

END

ELSE

PRINT 'Setting already exists for organisation'

[/code]

Once the script has executed you will need to reset IIS on your CRM server via iisreset /restart at the command line.

Now when you try to add users again via the Add Multiple Users wizard, you will only be able to see users belonging to the OU specified

Remember, you are doing this at your own risk!

Read more ...

Import a Solution Without Form Customisations

I've been using a solution recently which I really like, but it has added quite a lot of new fields, tabs, sections etc to my default entity forms which I didn't really need.

I want some of the features of the solution, but without the form customisations. To get around this I took a look inside the solution zip file.

Note: You should check that the solution does not require the form changes by performing this on a dev system first. Also, make a backup copy of the solution and your MSCRM database. In this case, I'm using a managed solution, so the changes can be easily reversed by uninstalling.

I extracted the customizations.xml file to my machine ad opened it up in Notepad++. In this case we'll look at the Account entity

If you scroll through the Account entity, you'll eventually get to the <FormXml> element. I find it easier to minimise the <EntityInfo> element to save scrolling through 2500+ lines.

The <FormXml> element contains all of the form customisations which are going to be imported i.e. fields to display, sections on-load/on-save script etc.

This element does not contain the field definitions or web resources themselves. Fields are defined within the <EntityInfo> element and web resources are stored within another folder in the solution zip file.

Remove the whole <FormXml> element from within the Account entity. I also did the same to the Contact entity

See the full gallery on Posterous

Now we need to save the customizations.xml file and put it back into the solution zip file. You will be overwriting the customizations.xml file which came with the solution, so please make sure you have a back up of this first.

The solution can now be imported into CRM. Once imported, check out the entities from which you removed the form customisation. They should still be in the same pre-solution state.

You should also be able to see the fields added to entity by the solution by entering the customisation screen. If you want to add any of the fields to your forms which the solution may rely on, you can do that manually here.

Read more ...

CRM Email Router and Office 365

Normal 0 false false false false EN-GB X-NONE X-NONE

We were recently moved from Microsoft Business Productivity Online Standard Suite (BPOS) to the new Office 365 platform.

BPOS was built on the 2007 range of Microsoft’s server products, so the step up to SharePoint and Exchange 2010 is very welcome.

However, I needed to reconfigure our CRM email router to process emails from the new system.

I tried all sorts of weird and wonderful email server URLs and kept being greeted by ‘401 Unauthorised errors’. Using auto-discover seemed to work for a few of the mailboxes, but it was very slow and occasionally stopped working until the Email Router service was restarted.

Finally, I got it working. After accessing webmail from the 365 portal, take the URL from the address bar and adapt it for the Exchange web service URL e.g.

becomes...

My Email Router configuration profiles for both outgoing and incoming mail look like this: -

Now when testing the connection on users and queues, I’m greeted with the familiar Incoming Status: Succeeded message.

Another problem I faced was user passwords being incorrect. Before you are transitioned to Office 365, Microsoft advises you to change your BPOS password, so that it is replicated in the 365 system. If users don’t do this, they won’t be able to access their email until the transition has been marked as complete. Until it has completed, neither administrators or Microsoft support  can reset passwords.

Frustratingly, it took 5 days to complete our transition, so some of our users were locked out for quite some time.

Luckily, if the user can remember their old password, they can still sign in with the Microsoft Online Sign-In tool, change their password and then log into Office 365. If they can’t remember it, pray that your transition is a fast one!

Read more ...