Hounds of Love…
In order to understand what it is really like for our customers and partners to install, customise and use MSCRM 3.0, we decided to “Eat Our Own Dog Food” (such a pleasant turn of phrase don’t you think) and use the product within the UK CRM team. So with my merry band of willing volunteers (in fact I would go so far as to say that Jason, David, Jez and Ollie were more desperate than willing), I grabbed some old-ish servers and started.
Now the first obstacle was that I am not a Domain Administrator or Exchange Administrator on the Microsoft corporate network (which is a good thing), and although I had done plenty of installs of the various beta versions using Virtual PC environments, I was always the Admin. Luckily, the unattended install file provides me with a way of solving this problem.
Firstly, I had to manually set up the four domain security groups in Active Directory. Luckily, we have a web-based tool in Microsoft (AutoGroup), which allows us to set-up distribution and security groups as well as manage the membership. So within a few minutes I had created the following security groups (group names have been changed to protect the innocent):
So now all I had to do was wait for Active Directory to do its replication-thing around the Microsoft network.
At this point you might be asking “Surely you need a CRM-specific Organisation Unit for theses groups?” Well it turns out that when you get asked for an OU during the attended CRM setup process, all you are really being asked is where setup should create the security groups for you. As I’m going to use an unattended setup file to tell CRM that I have some existing groups I would like it to use instead, I don’t need a dedicated OU for CRM.
You might also notice that my groups don’t have a GUID (Globally Unique ID) tacked on to the end of the group name. Well, the whole point of the GUID is to make sure that you have unique group names (Dohhh..!!) in the event that you install more than one CRM system in your network. Again, this is a sensible approach if you let CRM setup create these groups for you, but since we are doing this manually, you just need to choose different names yourself.
So next I installed 4 servers running Windows Server 2003 Enterprise Edition. My plan was to use one server as the CRM application Server, one as the SQL Reporting Server, one as the SQL Database Server and the forth running Microsoft Operations Manager (more on this later). Being an adventurous sort of person, and seeing as SQL Server 2005 had just been Released to Manufacturing (RTM – the final version) the week before, I decided to use both SQL Server 2005 and SQL Server 2005 Reporting Services, even though I had never installed either product before. OK so maybe adventurous is the wrong word and perhaps sad-techie might be more appropriate.
So after a day inserting CDs and watching Windows progress bars 4-times over, I had my four servers (server names have been changed to protect the innocent):
- CRM01 – CRM Application Server
- RPT01 – SQL Reporting Server
- SQL01 – SQL Database Server
- MOM01 – Microsoft Operations Manager Server
The next task was to get add these to the Microsoft corporate domain as member servers, Luckily, Microsoft IT have an enlightened security policy which means that all user accounts have the “Add workstations to domain” user right. I guess when a large proportion of your users are technical and need to build systems day-in, day-out it would seem sensible to grant them certain rights like this.
The beauty of our security policy means that all domain servers and workstations, automatically get patched with the latest service packs, hot-fixes and up-to-date corporate anti-virus, so I left the servers overnight and returned to them the next morning to find everything ready to go.
To be continued…
This posting is provided “AS IS” with no warranties, and confers no rights.