Team Foundation Server 2005 Workgroup

What an aboslute beast of a child!

I now have the displeasure of installing this development environment. The nice thing about the installation is the installation guide. The steps involved are in my opinion, second-rate for a multi-billion dollar company.

The requirements are laid out fairly well. You need:

Server 2003 (check)
IIS 6 with ASP.NET (check)
SharePoint Services (doc didn't work for me here)
SQL 2005 (no SP worked for me, applying it afterwards)

The main caveat for anyone attempting to install, is to follow the guide, and utilize the different accounts for their roles, or you will run in problems while installing.

One feature I do like is how the pre-installation checks take place. These need to go much further though. For example, you need IIS to be freshly installed, that means no Virtual Server or any other website installed. Virtual Server 2005 R2 is at least kind enough in their installation steps to warn you of the potential issues installing on other than the default website will cause. Quite simply, Team Foundation web tier (unless you are an absolute whiz on IIS 6) demands sole existence.

The other issue I had was with the SharePoint installation. While it's easy enough to appreciate you must manually install sharepoint so as to not use MSDE, make sure you don't make any configuration changes on the default admin website or again, you will have to start from scratch. The same goes for the reporting services, don't touch it, no matter how much you think you may need to for permissions or whatever. The Team Foundation installation will handle all of it. What I found perplexing is while the default installation of Sharepoint Services 2.0 SP2 worked fine, when I tried to install Sharepoint Services 3.0 (and yes folks, 3.0 is listed in the installation manual), the Team Foundation installation demanded SharePoint Services 2.0 with SP2! This was the only descrepancy I found in an otherwise well-written installation document.

Once the installation completes with success, you are not given much direction as for what to do next. In order to now actually use this, one must have the Team Explorer application installed/added in to their existing Visual Studio 2005 setup. This is done by using the Team Foundation Server setup program, and selecting that option.

After the installation completes the first step is to add users/groups to the foundation server, using the account you installed with, on the foundation server. Open Visual Studio, then click on the newly created Team menu item. From there you navigate to Team Foundation Studio Configuration, then go to groups. The interface here is pretty self-explanatory. You add the users/groups for permissions to the default security groups or create your own. All should then work, right? Wrong. For users to use Team Foundation Workgroup (standard requires purchase of its own license), each user must be individually added to the Licenses group. That original user for installation will appear here (that's who you're logged in to get to this point). Once you add at least one other administrator, you can then log out, use the new administrator, then remove the installation account to make use of all five licensed connections.

Once the installation finally goes ahead, everything runs fairly smooth. In conclusion, I found the installation to have some very positive areas, and some areas that could build upon the Virtual Server installation scenario. It was a bit like having a family member refuse to sit and eat at the dinner table because the plates/forks/etc were not set to their liking.

Virtual PC Time Synchronization

Today I received a question on how to disable the VM time synch with its host. The answer for this is not as straight-forward as it is with VMWare.

http://blogs.msdn.com/virtual_pc_guy/archive/2007/11/28/disabling-time-synchronization-under-virtual-pc-2007.aspx

In short, adjust the .vmrc xml file to include the following tags (under mouse is fine)



false



At least it is in XML

Remotely Logging Off Terminal Service Users

This guy has a contrite posting on the matter:

http://www.danrigsby.com/blog/index.php/2008/08/26/remotely-log-off-remote-desktop-users/

Ready, IPSEC, No Communication

That was the problem I had recently experienced with the application of updates MS09-045 and MS08-049 in tandem. The machine this took place on also doubles as an EndPoint Security Server (which invites its own slew of issues).

The handy work of Ant Drewery at http://www.drewery.net/blog/2006/04/18/failure-of-ipsec-services/#comment-40309 helped send me in the right direction. Looks like petri may have some competition!

The issue occured after trying to restart the machine after installing updates. For whatever reason, the system just did not want to bounce. Despite about 3 attempted restart /f commands. Upon it coming back up, there was no network connectivity to the outside world. IPSEC had ceased all that communication quite nicely.

To resolve - I re-registered a dll with the following command:

regsvr32 polestor.dll

Upon restart all works nicely! This is on a 2003 SP2 client with a 2003 SP2 Domain Controler.

More IIS 6.0 Fun

Several months ago, I set up a new network environment that was not live at the time.  That environment, once up and running and ready, was then utilized by some outside consultants and developers as an ad-hoc testbed.  Ultimately, The work carried out was not entirely (I am starting to doubt this every happens) removed or cleared up, so the system was back in its original state.  Luckily (or smartly), a complete backup of the system state, the IIS metabase, and the IIS configuration and directoy structures were made before access was given.  This allowed me two options:

 

1) Figure out what got changed and how to undo those changes

2) Restore the system settings, configuration, metabase, and directory structure.

 

Time not being of the essence, I chose the former.

 

When websites utilize an anonymouse user, that user can either be the default (IWAM?) user, or any other user you choose to specify in either a domain or local machine.  When this happens, or if any other site on IIS, or Virtual site utilize a non-default anonymous user, this poses frustrating authentication problems.  There are two ways (maybe three, but I didn't have any luck with the adsutil.vbs approach of synchronizing the passwords) that I was able to resynch the ever-changing anonymous user password hash.  The first is to route out all descrpencies for each and every incarnation of the mismatch for the user in the metabase (Make sure you are able to edit the metabase directly if you want to try this dicey approach.

 

The more-straight-forward approach that is much much safer to use is to disable all authentication for each website and virtual website.  Once that is done, you can go back and start enabling the anonymous authentication.  What is happening underneath the hood, is you are allowing IIS to automagically handle all the password hashes on the metabase by removing them.  Then as you re-enable this for each website or Virtual website, IIS will automatically ensure the passwords are synchronized when you select the other sites in the Apply Changes Prompt.

 

What causes them to get out of synch!?

 

This, thus far in my experience is not terribly easy to explain.  From what I can gather in the limited testing I have done, lets say you have siteA and virtualSiteA.  If you disable the synchronization on siteA then later re-enable it, you need to select any and all virtual sites when prompted to apply the authentication changes to.  If this doesn't happen, then oldest password hash (now virtualSiteA) is going to have the only legitamite hash to authenticate against, and the rest of your sites will not operate the way you want/need them to.

 

So, before you go out and start messing with Application Pools, or deleting and recreating users, try the above (no warranties!  Use entirely at your own Risk!).

SQL Data Types

So now that I'm studying for my 70-431 exam fully, I am writing out the datatypes:

 

• Exact Numeric (Used for precision data)
• Approximate Numeric (Used rarely, and appears to me to be a hangover from C)
• DateTime
• Money
• Character
• Binary  (this includes the image type most likely usedin Sharepoint for storing documents)
• Specialized (identity for primary keys, GUIDs, are two examples here)

Constraints:

• Check Constraints (These are set on tables)
• Rules (These are being phased out if not already in 2008, do not use), can be used outside of a table
• Unique Constraints (Prevents duplicate values in columns)
• Default Constraints
• Primary Key
• Foreign Key (this constraint ensures the value exists in another table already)

 

Scheduled Tasks are a Sensitive thing!

The other day after restriction of service accounts on a network, I was faced with troubleshooting why some scheduled tasks stopped running.  The accounts that ran the tasks were no longer part of the administrators group on the local machine in an Active Directory environment.  Not even Power User or Serer Operator group will work for you here, and we are referring to Server 2003 +

 

I believe the best practice is to create a domain user, and then incorporate that account in to each local machine's local Administrators Group as necessary to perform its tasks.

Network Monitor and the SSL Handshake with DNS

Recently I found myself migrating a system to a new data centre. During that testing a user realized that their process for submitting data was not working.

Despite the website working, the submission to an ASP link over HTTPS kept returning errors that the specified file cannot be found.

After quite a bit of time, the root cause was addressed down to DNS. I missed an early-on fundamental question of whether or not they utilize the hosts file on their system they were submitting information with. As it turns out, there was a typo in the domain name entered in to the hosts file!

So what ultimately what led us back to that (It was reassured previously this was not the problem and the link was fine) was the use of Network Monitor to watch the SSL handshake.

The following link provided a nice rundown showing the mechanisms on a Windows Server:
http://support.microsoft.com/kb/257587

It was in the packet details that I realized that not only was the site certificate being sent, but it was also sending the parent Certificate Authority also. The sending of the parent CA only happens when the initial website SSL certificate does not get trusted by the connecting client. This can happen for any number of reasons, like out of date revocation lists, CA updates not applied, or, in my experience here, a typo in the LM Hosts file.

So, wait a minute, why didn't it just use DNS? Well, the specification of DNS in 1034/1035 (Forget which) has a DNS client follow a very specific method of resolving a name to an IP address.

1) Client checks the local hosts file
2) Client checks its local memory cache
3) Client queries a DNS server (a second one if no response)
(client may try to query a root server at this also depending configuration and definition of a DNS client)
4) Client waits for a response

So why does the hosts file get looked at first and not the local cache? This occurs because the history of DNS. Back before the hierarchial querying was established, ALL of the internet DNS was held in a hosts file. Once this became unmanageable, DNS in its current incarnation (more or less) was formed.

WSUS 3.0 and .NET 2.0 SP1

Today after installing patches to the WSUS server, it stopped working after the restart.

What I should have done, is take a nice backup of the System state before installing the patches!

In any case, upon restart the machine came up, but the following types of errors came up:

I had to set the Web Publishing service to NOT allow desktop interaction

ASP.NET 2.0.50727.0 EventId 1314 appeared in the event log with the following error:

Even code: 4011
Event message: An unhandled access exception has occurred.
..... etc.

I got to the point where I had no authentiation mechanism, eventhough all services were running. No users in the WSUS local groups... strange...

So, rather than removing the patches, I have uninstalled WSUS and reinstalled (leaving all the information in-tact, db, log and one other option I can't remember). The problem with this is that I will still most likely have the same underlying issue and need to manually uninstall the updates I have applied before the installation.

Upon second attempt at reinstallation... it worked.