Grant Thompson's Blog

When installing Team Foundation Server 2008 using an existing MOSS deployment we ran into the following error:

TFS2200401: The specified Windows SharePoint Services site URL (http://server) is not the default site collection site: (). The default site collection site might have been renamed or removed. Make sure that the site exists and verify the correct URL, and then attempt installation. If the problem persists, you can choose to install and configure Windows SharePoint Services as part of the Team Foundation Server installation process.

I looked at the install log file: dd_install_vstf_at_90.txt and found:

wsschecker.exe : Another site already exists at http://server. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.

I tried a few different things with no luck.

Resolution:

In the end I created a new site collection (interesting the existing site collection was at http://server and not http://server/sites/x). When I created the new site collection I was given the default http://server/sites/ option and filled in a new URL. TFS installed fine from there.

Now we have to integrate the TFS site collection into the client's existing site collection or migrate their old site collection to the new one. J

I've seen a lot written about this particular issue. We just ran across this yesterday and here is how I solved it.

Symptoms:

Logging in to the MOSS/WSS Central Administration web site works fine from the local machine (MOSS central admin server) but when logging in from remote machines an NTLM prompt is presented and domain admin, domain farm admin, etc. accounts are "not authorized". The typical behavior of the NTLM prompt coming up three times before the error page (401.1) is displayed.

However, I found that if I logged in as the local machine administrator (of the MOSS server) it worked fine. For example DOMAIN\Administrator fails but SERVERNAME\Administrator works.

Troubleshooting:

It was clear to me that this was an authentication problem and had nothing to do with MOSS. To test my theory I created a simple web site in IIS and turned off anonymous access. Then I tried connecting to that site remotely and it worked. I had actually expected it to fail. Next I set my test web site to use the same application pool as central admin. This time my test site behaved the same as central admin. The common thread here is Kerberos authentication was not working when run using the central admin app pool user account.

I ran SetSPN (you can download this from www.Microsoft.com/downloads if you don't have it) –L domain\moss central admin account (in this case domain\MOSS_CA). Sure enough there were no entries.

Resolution:

Run SetSPN –A http/server.domain.local domain\MOSS_CA (remember that you need to substitute your server, domain and account).

Next open Active Directory Users and Computers (with access to your domain's AD) and find the domain\MOSS_CA account (whatever your central admin app pool is running under) and open properties. Click on the Delegation tab and choose "Trust this user/computer for delegation to any service (Kerberos)".

At this point I had to reset the password on the service(s) using the account and update the account's permissions in SQL Server. Then I rebooted and everything was working properly.

If you need additional information (i.e. more details about where to find your Central Admin app pool account, etc.) leave a comment and I'll do my best to get back to you.

Setting up a Microsoft Dynamics CRM 3.0 system where the laptop clients are running Windows Vista and Microsoft Office Outlook 2007 I attempted to install the laptop client from the CRM_VC3_CLIENT.iso which is for Vista and Outlook 2007 (get it here). NOTE: this is for "on premise" for service providers there is a different ISO.

The error I got (see below) is:

The type initialize for
"Microsoft.Crm.Setup.Common.CommonResource" threw an
exception.
File or assembly name Microsoft.Crm, or one of its dependencies, was
not found.

The first problem was easily fixed:

The System Requirements screen said that the Indexing Service was not installed – this is used for backward compatibility in Vista. To resolve I opened Appwiz.cpl and installed the Indexing Service.

No big deal. To ensure everything was clean I did a reboot. Then I ran setup again and got this:

I did a Google search and came up empty (except for others asking how to fix it). So here's the fix:

1. Disable and stop the Indexing Service
   1. Open services.msc
   2. Open the Indexing Service properties page
   3. Set it to disabled and stop it
   4. Click Apply
      
      
2. Run the CRM client setup again. This time you will get back to the System Requirements screen and see the following:
   
   
3. Leave setup open and go back to services and set Indexing Service to automatic and start it (note: you must click Apply after setting it to Automatic before you can start it).
   
   
4. Lastly, go back to the CRM setup System Requirements dialog and click Back and then Next and finish your install.

Hope this helps

This is a general error but here's where I ran across it.

On a network running SBS 2K3 R2 we were troubleshooting use of IPv6. We had it working on another server and one thing we did was compare installed updates. On the functioning server an update named "Windows Small Business Server 2003 R2" was listed. So we reinstalled the R2 technologies on the non-working server.

Then came the problems, first RPC via HTTP stopped working. After finding that RPC was disabled and enabling it (did not fix the issue) the Active Sync issue appeared.

The solutions was to enable Integrated Windows authentication on the exchange-oma virtual directory.

1. Open IIS
2. expand to Web Sites\Default Web Site
3. right-click exchange-oma and choose properties
4. click the Directory Security tab
5. click the Edit button in Authentication and access control
6. check the Integrated Windows authentication box
7. click OK twice

On Windows XP SP2 I have run across this error a few times. Typically it is an unhandled exception in C:\Windows\msiexec.exe when trying to open Outlook for the first time. Detect and Repair Outlook (or other Microsoft Office applications returns the same error. No Office Updates will install.

I never determined the exact cause of the error but the following steps solved it.

1. Download all versions of the .NET framework from www.microsoft.com/downloads (at the time this post was written they were 1.0, 1.1, 2.0 and 3.0)
2. Install 1.0 then 1.1 then 2.0 then 3.0 - each time choosing reinstall or repair.
3. Reboot the machine
4. Repair Outlook or Office
5. Install Windows Updates and Office Updates (optional but recommended)
6. Test

I believe this is corruption in the .NET framework somewhere along the way that breaks the C++Runtime Library.

Here are the downloads:

1.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=d7158dee-a83f-4e21-b05a-009d06457787&DisplayLang=en

1.1 http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&DisplayLang=en

2.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en

3.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en

1. Create (or have the user create) and invitation file and send it to you or save it somewhere you can get it (i.e. a network share). Ensure the invitation is created using the Administrator account (or another account with privileges you need).
   1. Log on to the machine you want to control as Administrator
   2. Click Start/Help and Support
   3. Click Invite a friend to connect to your computer with Remote Assistance
      
   4. Click Invite someone to help you
      
   5. Choose your delivery method - depending on what is functioning on the machine Save invitation as a file (Advanced) is usually the best
      
   6. Accept the default name and expiration or change them as needed. NOTE: If the session will require a reboot you may want to extend the invitation expiration so you can use the same invitation to connect over a period of more than 1 hour.
      
   7. Click Continue
   8. Enter a password - using a password is recommended but not required. If you choose not to use a password uncheck the Require the recipient to use a password box
      
   9. Click Save Invitation (or Send Invitation) - note if you use IM this is different
2. Reboot the machine in Safe Mode with Network Support. You can do this with MSConfig:
   1. Click Start/Run, type msconfig and click OK
   2. Click the BOOT.INI tab
   3. Select the /SAFEBOOT option and the NETWORK radio button
      
   4. Click OK and reboot the machine
   5. Log in as the user that created the invitation
3. Open the invitation file from the computer you are connecting FROM
4. On the remote computer accept the Remote Assistance session
   
5. Initiate control on the computer you are connecting FROM
6. On the remote computer accept the remote control request

To turn off safe mode if you used MSConfig:

1. Click Start/Run, type msconfig and click OK
2. On the General tab choose Normal Startup
   
3. Click OK and reboot the machine

NOTE: If the ESC key is pressed on either machine Remote Control will be lost and the machine you are connecting to will have to accept it again. The ESC key cannot be pressed in key combinations (i.e. CTRL+ESC will stop remote control). Likewise a reboot will require steps 3-6 be repeated.

When you setup an FTP server on a Windows Server 2003 system you may run into this issue if you are using RRAS and have configured the server as an Application Server (which causes the Application Layer Gateway service to start). There is a known issue with FTP and this configuration for downloading large files. However this can also affect an FTP server where "Allow anonymous connections" has been disabled.

To solve this you must configure the Application Layer Gateway (ALG) service to not make port mappings for your FTP server.

Here is the fix:

1. On the server open Regedit
2. Navigate to HKLM\Software\Microsoft\ALG\ISV
   
3. Change the value of {6E590D61-F6BC-4dad-AC21-7DC40D304059} to Disable NOTE: not Disabled.
   

An IISReset is not required.

The Microsoft KB related to the large file download issue is here: http://support.microsoft.com/kb/931130/en-us

Thanks to Mark for setting up blogs for our company.