Microsoft Dynamics CRM

The other day I installed CRM 2011 into one of our environments. I had setup the environment as is recommended in the deployment guide, with multiple service users and all of the security permissions set on the local machine; like I had done on many other environments before. The installation went well. There were no errors and I could create new organizations and what not. However the problem came when I attempted to logon. I was fairly certain that I had entered the correct credentials, and at this stage there was only the deployment administrator added to the deployment. I thought that maybe the deployment administrator hadn’t been added to the organization, even though it said it had been in the Deployment Manager. So I checked the database and sure enough it was in there.  “Very odd” I thought. So I did what every admin in my shoes would do and checked the Event Viewer. I found this:

Thinking this might have been some kind of security issue I double checked all of my security settings on the local machine and on the AD server. But alas, there was no visible problem. So I consulted Old Man Google. Seeing as I followed the deployment guide pretty well, I assumed that someone else must have had this issue. Unfortunately, I found that there were lots of people with the same issue, except with no resolutions.

I found someone that mentioned that the DNS server was off in their environment and turning it back on solved the problem. I knew that all was well with our DNS so it couldn’t have been that. I found another that said: Setting “Load User Profile” to True for the IIS Application Pool “Microsoft Team Foundation Server Application Pool” worked for them. They didn’t say what version of CRM it was but at that point I was willing to give anything a go! But that failed as well. Unfortunately there was no other knowledge that Old Man Google could bestow upon me.

After wracking my brain and re, re, re-reading the deployment guide; I remembered another issue that I had in this environment. Quite a while ago, I was deploying another application that also used Service Users that I had to create for that application; and I had a very similar problem. The application couldn’t read the Active Directory. I found that if I changed the service users to be domain administrators, the problem went away. So I tried that out on this CRM 2011 deployment and the results were the same!

What had happened was that before my time. In the Jurassic period; when this Active Directory was created, the person who created it didn’t want the average user to be able to read attributes from the Active Directory. Thus, they changed the level of permission (or so I assume) accordingly and created a security group who could read attributes.

After I added my service users to this special group, removed them from the Domain Admins group and restarted all of the CRM 2011 services.  The problem was forever solved!

What I really wanted to say in this post was that the error I mentioned earlier appears to occur when the Active Directory cannot be read by the service users. So check your DNS is running and that AD is working correctly. If all seems well, try temporarily adding your service users to the domain admin group or some group that would have the power to read the domain attributes and see if that rectifies your issue. If it does, your issue will most likely have a similar solution to mine. If not, I hope this post at least points you in the right direction!

Kyle Smith

When you have the task of designing a large workflow it can be tempting if not logical to want to create just that, one large workflow.  It’s neat, it’s all in the one place and it should be fine right? Unfortunately not.  I have recently learned the hard way that making one hulking workflow is a bad idea.

The Problem with one large Workflow

The problem with making one big workflow that does everything is that it is much harder and far more time consuming to edit than making a lot of smaller ones. There are a few reasons for this, one being that once you have your workflow completed, you will notice that it is incredibly slow. It can take up to 15 minutes to load anything; and before you know it you have spent half your day (or more) just waiting for pages to load.  Another is that when you want to edit your workflow you have to unpublish it. The bit that you want to edit may only be small and affect only a few users, but because this is an all-in-one workflow, everyone may be effected for 45 minutes or longer.  These are just a few good reasons to not build one large workflow, but enough of what not to do. I think it is time we got on to what we should do when we design large workflows.

Find and isolate the common operations of your workflow.

Before you begin building a workflow you need to have some idea of what you want it to d0 and how it is going to work. Sometimes drawing a map can help this thought process.  However, mainly what you need to do is identify what parts of the workflow are the parts that will be reused, such an example might be a standard email that is used to alert a queue that a case/request has been assigned to it. If you want this same email to be used more than once in the workflow, you should build a child workflow and reference that whenever you need the email to be sent. This way when you need to make changes to the layout or wording later on; you can edit it in one spot and the changes will affect all parts of the workflow without unpublishing everything.

The Master workflow

It’s important that when you are creating all of these child workflows you don’t get any funny ideas that they should operate on their own. In other words, you make eight workflows that all fire on the same action. i.e. when a record is created. This would mean that all of those workflows are checking this record at once, even if they aren’t related to it. This will cause performance issues on the server and for no good reason.  So what you need is what I like to call a Master workflow. It is a single workflow that is similar to a coarse filter; it is triggered by a record creation (or whatever you need). It then looks at the record and hands it to the appropriate child workflow, for the child to deal with it, that’s it. The whole purpose of the Master workflow is task delegation!

The name structure

You should create some sort of structure when you give names to your Workflows. These are the three rules to which I create my name structures:

Over the past month or so I have been migrating our internal virtual servers from Parallels Virtuozzo over to Microsoft’s Hyper-V.  The project has been ticking along nicely but unfortunately our resources reached a point of critical mass.  So in order to salvage some room from our existing resources that are being massively under utilised, my clever colleagues and I come up with the idea that we just run a Virtuozzo server inside a Hyper-V Virtual Machine. It was a suggestion that was meant as a joke but it was just so crazy that it might actually work.  After scouring the Interwebs with a fine toothed comb I could not find any info on anyone actually doing this.  Which usually means one of two things. It is impossible or no one has ever done it. 

So on with the first test

Our first test was to complete a P2V conversion of the server.  It worked! but not really.. It needed massive amounts of work to get it going and when it did it was as unstable as a pile of rickety old crates stacked precariously on a three legged chair.  Just as all hope for the idea seemed to be lost my colleague Ben Kramer being the clever cookie that he is, come up with a much better idea.  We deploy a fresh virtual machine, install Virtuozzo on it and then migrate the Virtuozzo containers (VMs) to the new server. 

It just worked! 

Right away this new plan felt like a much better way to get the job done. As I was installing Virtuozzo on the new VM, I was expecting to see some kind of compatibility issue, some kind of error or reason that Virtuozzo would not install on the system.  But thankfully there was none of that, it just worked! 

Now for the real test

Our last test was to migrate the containers. I tested it using some old dev servers that where pretty much not used now, and I was amazed to see that they worked with no issue.  The other servers where later moved with no issues that related to the Hyper-V environment.

So to sum the whole thing up

We now have a Virtuozzo environment running quite well inside a Hyper-V environment.  We also now have three Hyper-V Hosts with the resources spread out quite well between them. As opposed to before where we had two overloaded Hyper-V Hosts and one under utilised Virtuozzo Host.

I hope this post was informative and useful to any one who has to do the same thing.

Kyle Smith

JayThom are currently looking to expand our development team. For more details please check out the JayThom Employment page on our website.

The lastest Update Rollup for the CRM has been release today.

http://support.microsoft.com/default.aspx?kbid=981328

JayThom had it’s first project kickoff meeting on Tuesday with security and investigative services company, SecureCorp. Information gathering is underway and implementation is due to begin this week.

Director of JayThom, Brett Yorgey, will be speaking at the Microsoft WPC in New Orleans in June this year. He will be showcasing JayThom’s most recent innovation, CouncilRM™, a solution built for the local government sector to manage relationships.

User Acceptance Training was a success for Baw Baw’s Customer Service Officers and has been fully deployed by the department. Baw Baw is now looking at rolling out CouncilRM™ to the rest of the Shire.

Muhimbi has designed a display for Microsoft Word files to be read from your SharePoint document library!

http://www.muhimbi.com/blog/2009/04/displaying-ms-word-files-in-sharepoint.html

We’ve had a successful period of User Acceptance Testing which is due for completion at the end of this week. User Training is will commence next week, 11th and 12th February and Baw Baw will be ready to go live on the 4th of March!