Ben’s Tech Blog

I recently built some Microsoft CRM 3.0 servers and came across a problem when trying to create the CRM databases on a SQL server. The CRM installation routine was returning the following error:

Action Microsoft.Crm.Setup.Server.InstallDatabaseAction failed.
The Microsoft Search service cannot be administered under the present user account

I made sure that the account that I was using to install CRM (and effectively create the CRM databases) had local admin rights on the SQL server. As it turned out, this problem was actually caused by a documented issue where the Microsoft Search Service can become out of sync with the SQL service account if the SQL service account is changed via the services applet instead of Enterprise Manager. As the following article explains, when the service account is changed via Enterprise Manager, SQL Server adds itself as an administrator to the Microsoft Search Service.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;277549

Once I changed the service account to use the system account, and then back to the domain service account via Enterprise Manager I was able to successfully create the CRM databases during the CRM installation routine.

The Windows Server 2003 Active Directory Users and Computers snap-in (ADUC) includes the ‘Saved Queries’ feature which allows you to save queries for future use. One of the nice things about this feature is that once you save the query you can view the actual LDAP query string. You can then proceed to customize the string, or copy and paste it into a script for example.

The biggest shortfall that I see with the ADUC find/search utility, is when it comes to selecting a Condition, and this is where you may need to customise a LDAP query. The drop-down allows you to choose from Starts with or Ends with etc, but what about Contains? If you want to search all users to find a description for example that contains a word or phrase anywhere in the description you can’t using the standard method. This is where using a saved query comes in handy.

The easiest way to construct a custom query is to start by creating a query that is close to what you would like to search for. In this case you could construct the query by using either Starts with or Ends with as the condition, and then modify the query string once its saved. I’ll run through this now.

1. Right click on Saved Queries, then Select New -> Query.
2. Give the query a name, then click on Define Query
3. In this example, we’ll just search users, so select Custom Search from the drop-down.
4. Click on the Field button and select User -> Description.
5. Select Starts with and enter the text that you want to search for, e.g “test lab”, then click on Add.
6. Click on OK. Notice that the Query string field is now populated. Highlight and copy the Query string text and click on Define Query again.
7. Higlhight the criteria that you added before and click on Remove.
8. Click on the Advanced tab, and then paste in the query text
9. At this point you can now customise the query text. To search for descriptions that contain “test lab”, you need an asterix (*) on either side of the text. So you need to add an asterix to the end of the search text so that it looks like the text in the image below.

10. Click on OK, then OK again.
11. Right click on the Saved Query and click on Refresh. You’ll see that users with “test lab” anywhere in the description will be listed, for example, a user with “Sydney test lab user account” as the description would be listed in the results.

Of course, customizing your LDAP searches can allow you to do a lot more than what I just demonstrated. If you start exploring ADSI Edit you’ll find more attributes of objects that you can search on that aren’t listed in the ADUC search fields. For example, if you wanted to search for all users that have mailboxes on a particular Exchange server, you could use the msExchHomeServerName attribute. Your LDAP query would like something like this:

(&(&(objectCategory=user)(msExchHomeServerName=/o=OrgName/ou=AdminGroupName
/cn=Configuration/cn=Servers/cn=ServerName)))

The LDAP queries that you construct aren’t limited for use in ADUC, you can implement them in scripts that perform LDAP queries or third-party software that performs LDAP lookups for example. The ADUC saved queries feature just allows you to construct the basic query, from there you can modify it to do what you need. I should point out that you can also construct LDAP queries and view the LDAP string when you create Query-based distribution lists, or Exchange Address Lists/GALs.

When you connect to a resource on another machine and supply a username/password, you are given the option to “save password”. It took me a little while to find where these credentials are stored in Windows XP, so I thought I’d share it with you.

The process is slightly different depending on whether or not the logged on user has local admin rights.

Viewing cached credentials – with Admin rights

Viewing cached credentials – without Admin rights

In either case, you will be presented with the following box that allows you to add, remove or modify cached credentials.

One of the issues that I’ve come across at various times in the past is that you can only authenticate to a machine with a single set of credentials. In other words, if you map a drive to \\server1\share1 as UserA, then you cannot map a drive to \\server1\share2 as UserB. You need to use a single user account that has access to both shares.

A while back we needed users to access resources on a server in an untrusted domain (in other words, there was no trust relationship between the two domains/forests). Because the server was in and untrusted domain, users were prompted for a username and password when they tried to access an application stored on the server. We created a generic account in the destination domain so that users could connect to the server and access the application. However, the server was also a file server, and some users needed to access another share with a specific user account that the generic account didn’t have access to. The problem was that the users had already connected to the server with the generic account and had saved the password. This is where being able to remove the saved credentials came in handy. Once we removed the cached credentials of the generic account, we could then have users connect to the server with the specific account and access both the application and the data share.

Dealing with Member Servers

Re-deploying services

In some cases, rather than migrating a server from an NT4 domain, it made more sense to transfer the server’s function to another server or device. For example, DHCP was running on the PDC of one of the legacy domains to issue IP address leases to the workstations in their subnet. I opted to move the function to our switches. We are using 2 Cisco Catalyst 4507 switches; I worked with our network services team (the Cisco guys) to move the scopes from the NT4 server to the 2 switches. Each switch was given it’s own pool of IP addresses for redundancy and load-balancing.

Migrating Member Servers

There were several servers which needed to remain in use. For these servers the migration from their existing NT4 domain to the AD domain was as simple as removing them from the NT4 domain and adding them to the AD domain. The service accounts and ACLs on objects were already using groups from the AD domain (there were external trusts in place between the AD domain and the NT4 domains), and when I added the servers to AD users were still able to access resources on the servers. I tested this process in a lab before migrating the actual production servers.

Decommissioning the actual Domain

Removing the last Domain Controllers

I have completely decommissioned 1 domain so far, with the remaing 2 domains almost done. My aim was to remove all member servers until I was down to a PDC and a BDC. Once I got to that point, I disabled all of the user accounts except for the Administrator and REPL accounts. After a fews days, I then removed the trust relationships.

I took a backup of the PDC, but I wanted to have a very easy way to bring the domain back up if I needed to in future. I considered relying on a Ghost image, but that would require that the image be dumped back to the same hardware, and I knew that the hardware would be scrapped in the near future, leaving the image useless. Although I had the standard backup of the OS, I didn’t want to have to go through the whole restore process if for whatever reason I needed to bring a domain controller back up. My solution was to build an NT4 server in a Virtual PC image and promote it to a BDC in the legacy domain. Once I confirmed that the database had replicated, I shut down the domain controllers and burnt the Virtual PC image to DVD. If I need to bring the domain back up in future, it will be a simple case of starting the VPC session.

I’m in the process of decommissioning three NT4 domains as well as some legacy servers.  The domains had previously remained in place as we had some Windows NT 4.0 EIC telephony servers and an underlying Exchange 5.5 infrastructure that were dependant on them (EIC uses unified messaging).

I’m going to spread this post over more than one entry, the first part will cover the planning stage.

Planning

Identifying the domain’s dependencies

The first step in planning the project was to determine what was actually dependent on the domains.  Although I knew that the EIC and Exchange servers relied on the domains, there were some servers and service accounts that were still in use; these needed to be documented and assigned an action.  I created a MindManager map which listed each domain as a main topic, and each server within the domains as the immediate child topics.  Branching out from the servers was each service, server, or user group that was dependent on these servers.  I then used map markers to assign an action to each dependency.  This allowed me to start thinking about the order in which I could remove servers.  Naturally I can’t include the actual document for security reasons, so I’ve created a basic example of the dependencies mind map.  It contains enough detail to give you the general idea, but it’s far from complete.

Going through this exercise was very valuable; it’s something that I plan to do for each environment that I work in with in future.

Action Plan and Project Time Line

After creating the dependencies map, I created a Microsoft Project document.  The nice thing about Ms Project is that you can assign “predecessors” for each task.  This allowed me to translate what I had identified as dependencies in the mind map into an ordered list of tasks with predecessors.  For example, the server that hosts the EIC database cannot be decommissioned prior to the actual EIC server; therefore the task to decommission the EIC server became a predecessor of the task to decommission the EIC database server.  For each server to be decommissioned, I allocated a date for a final backup and to shut the server down.  I planned the actual hardware to be decommissioned several weeks after the server is shut down to leave enough time to back out.

A good friend of mine, Todd, sent me a link to this document:

Service overview and network port requirements for the Windows Server system 

The first section of the article contains a list of the Windows Server and client services with their corresponding TCP/UDP port numbers, sorted by the service itself.    The Exchange Server and Outlook clients section is quite comprehensive, with related articles regarding the use of static ports and information about RPC over HTTP.

The second part of the article contains a summary table sorted by port number to make it easy to identify which services listen on a particular port.

A valuable article.