Deleting Users in MS CRM 4.0

April 4, 2011 at 11:23 GMT+0000 · Filed under MSCRM 4.0

I have a SQL script (see below) which will allow you to delete a user fully and completely from Microsoft Dynamics CRM 4.0. It is, of course, utterly wrong and unsupported to do this, but still – the script exists and seems to work just fine.

I originally wrote it to carry out some particularly unsupported work with a previous client. Later on, I found use for it on more than one occasion during my own development (specifically when importing clients’ existing databases into my own Virtual Machines).

Some time ago, I pulled the script from here but I can no longer keep up with requests send it on. Consequently you can now find it at the end of this post.

I chose to remove it since even my own tenuous example of how it might be useful turned out to be overengineered. I had suggested that deleting users might be an easy option when importing databases full of users into a development environment, but where you the developer don’t want the overhead of creating AD accounts and then mapping those users. Ivan (comments, below) has correctly pointed out behaviour which I was previously aware of but had slipped my memory: mapping users is not mandatory during the “Import Organisation” process (well, you need to map at least one user, but otherwise…). Despite showing an “Error” during the mapping process, so long as at least one user has been mapped, one can opt to ignore the issue and proceed with the import. Thank  you Ivan.

In my opinion, there are very few (if any?) viable reasons to use this script, so I recommend that you exhaust all other options before considering using this script. Be aware that the reason you can’t delete a user in CRM is that there are usually different ways to approach the problem.

Read the rest of this entry »

Comments (53)

Campaign Response – required privileges (or “how to hide”)

September 29, 2010 at 13:16 GMT+0000 · Filed under MSCRM 4.0

I’ve only written the title and I’ve already over-promised…

So you want to suppress the Campaign Response activity but don’t want to start hacking at the CRM files. What options have you got? Very few, to be honest.

Entity visibility is driven via privileges and by turning off access to the right parts of the system, most things can be hidden. The problem comes with the side-effects. Since Campaign Response does not have an explicit permission-set in its own right, it is not obvious as to what needs to be changed to hide it from users. Here’s the solution – you can choose to remove access to either:

• Activity : [Append] AND Campaign : [AppendTo]
• OR Activity : [AppendTo]

By removing access to one of these two groups in the appropriate role(s), Campaign Activity will cease to be shown to all users that are subject to that role (assuming that they don;t have additional roles that grant these permissions). It’s a bit limiting though since without “Activity : AppendTo”, you’re not going to be able to add Notes or attachments to an Activity and without Activity : Append, you won’t be able to set Regarding…

I didn’t say that this would be helpful!

Comments

Which privilege failed?

September 13, 2010 at 15:06 GMT+0000 · Filed under MSCRM 4.0

A quick tip that might come in handy if you start editing roles and permissions in your CRM deployment. Often when I start to define completely custom roles, especially when using a brand new role with no existing values, I will encounter an error message when testing the role:

Error Description:
0x80040220 SecLib::CheckPrivilege failed. Returned hr = -2147220960, User: 00000000-0000-0000-0000-000000000000, PrivilegeId: a3311f47-2134-44ee-a258-6774018d4bc3 Platform

Error Details:
0x80040220
SecLib::CheckPrivilege failed. Returned hr = -2147220960, User: 00000000-0000-0000-0000-000000000000, PrivilegeId: a3311f47-2134-44ee-a258-6774018d4bc3
Platform

So what do I need to change to make this work? MSCRM isn’t being particularly helpful with this error message, so here’s how to make it make sense. Run the SQL script below against your [Organization]_MSCRM database. Replace the GUID in the query below with the PrivilegeId GUID in the error message:

select [Name] from dbo.PrivilegeBase where privilegeid = 'a3311f47-2134-44ee-a258-6774018d4bc3'

You should get a single result back, like ‘prvReadEntity’ (Read access required for “Entity” which is found on the Roles matrix under the Customization tab, Entity row, Read column) or ‘prvCreateUserSettings’ (Business Management tab, User Settings row, Create column). As you can see, the Name of the privilege should give you the pointer needed to set the required permissions.

Comments (1)

You are not a Deployment Administrator

June 4, 2010 at 10:01 GMT+0000 · Filed under MSCRM 4.0

We’ve all seen this error at some point when trying to access the Microsoft Dynamics CRM Deployment Manager on the server:

Only the Deployment Administrators are able to use Deployment Manager. You are not a Deployment Administrator.

Most of the time this is not a problem at all – perhaps you’re logged in with the wrong account or you simply need to request that another administrator logs in and adds you to this list. Sometimes it can be trickier though – perhaps the only administrator is on holiday, has left (and had their account deleted rather than just disabled) or any other number of things that might just ruin your day. The only supported method at this point is a reinstall of CRM. Cripes…!

How about an unsupported method to get you by?

Try this little SQL script which should add you to the list of Deployment Administrators. It is ENTIRELY UNSUPPORTED and probably shouldn’t be used in a production environment etc etc. But needs must and this might just save your day (but don’t blame me if I make it worse, right?).

IMPORTANT NOTE: This script will get you into the Deployment Administrator, but if you were NOT already a CRM user, it won’t get you into the CRM front-end. Clearly something missing from my script at present – be very very careful if you use this in production…

USE MSCRM_CONFIG

DECLARE @username AS VARCHAR(MAX) ,
        @newuserguid AS uniqueidentifier ,
        @userguid AS uniqueidentifier ,
        @adminroleguid AS uniqueidentifier

-- *** TODO:  ADD THE USERNAME YOU WANT TO MAKE A DEPLOYMENT ADMINISTRATOR HERE
SET @username           = '<domain>\<username>' 
SET @newuserguid        = NEWID()

-- Get guid for the Deployment Admin role
SELECT @adminroleguid = id
FROM   dbo.securityrole
WHERE  Name = 'Administrator'

-- Add the user as a systemuser (unless they already exist...)
IF NOT EXISTS
    (SELECT ID
    FROM    SYSTEMUSER
    WHERE   NAME = @username
    )
    BEGIN
            INSERT
            INTO   SYSTEMUSER VALUES
                   (
                          '00000000-0000-0000-0000-000000000000',
                          @newuserguid                            ,
                          @username                               ,
                          0
                   )
    END

-- Get the user's guid
SELECT @userguid = ID
FROM   SYSTEMUSER
WHERE  NAME = @username

-- Add the user's guid and the admin role to the SystemUserRoles table
INSERT
INTO   dbo.SystemUserRoles VALUES
       (
              NEWID()       ,
              @adminroleguid,
              @userguid   ,
              NULL          ,
              0
       )

We also may need to add the record to the appropriate AD groups and CRM tables. I’m not going to show you how to add items to Active Directory Groups or which groups to use. Suffice to say, you would need to know the user’s Active Directory sid (Security ID). Try this command from the server prompt:

dsquery user -name Greg* | dsget user -sid

This should return a result similar to this:

sid
S-1-5-21-0123456789-0123456789-0123456789-1234
dsget succeeded

You’re on your own from this point… 😉

Comments (5)

Dates in FetchXml queries

May 19, 2010 at 9:08 GMT+0000 · Filed under MSCRM 4.0

Another quick post. A colleague was trying to execute a FetchXml statement that included a filter on a date field but couldn’t understand why he was not returning the expected results (indeed, wasn’t returning any results).

At first glance, the query looked fine:

<fetch mapping="logical">
	<entity name="new_entity">
		<attribute name="new_entityid"></attribute>
		<filter type="and">
			<condition attribute="new_linkentityid" operator="eq" value="f25f4cee-e851-df11-bebe-000c29a1faa8"></condition>
			<condition attribute="new_date" operator="eq" value="2010-04-30"></condition>
		</filter>
	</entity>
</fetch>

The link entity was definitely correct and the date field certainly read 30th April 2010. The date field was also defined as Date Only in the attribute definition.

It transpired that the problem was (predictably) linked to times. CRM stores all dates in UTC format () so even if the attribute is defined as “Date Only” in the entity definition, 30th April 2010 will actually be stored as 2010-04-30T00:00:00. For some reason, which I haven’t yet determined for certain (there are a couple of theories that i don’t have time to test), the record he was seeking was dated 2010-04-30T08:00:00. It may be due to his time zone, since he was working in the US at the time of the problem. It may be that this attribute was previously a Date AND Time attribute and then got changed. Either way, the simplest solution was to use a different FetchXml operator – replacing the “eq” operator in the “new_date” condition with the “on” operator thereby ignoring times:

<fetch mapping="logical">
	<entity name="new_entity">
		<attribute name="new_entityid"></attribute>
		<filter type="and">
			<condition attribute="new_linkentityid" operator="eq" value="f25f4cee-e851-df11-bebe-000c29a1faa8"></condition>
			<condition attribute="new_date" operator="on" value="2010-04-30"></condition>
		</filter>
	</entity>
</fetch>

A list of FetchXml operators can be found on MSDN

Comments