Skip to main content

Move Team Foundation Server to a new domain

Since we want to simplify administration by minimizing our server farm the subdomain that currently hosts our Team Foundation Server is going to be removed. This means that we will have to move the entire installation to the parent domain. Luckily we only have one server as application-tier and data-tier, and we are very few users, which makes the process a whole lot less dramatic.

First of all we have to make sure that the new domain is ready to incorporate the server. It is not possible to perform any kind of user mapping, so all user accounts must have the same login name on the new domain as on the current domain. This also applies to the service accounts used by Team Foundation Server.

The documentation around this procedure is well documented on MSDN. The article describes the scenario to move from a workgroup to a domain, but the scenario from one domain to another works exactly the same. The entire process can be summarized in 5 steps:
  1. Ensure that all users have accounts on the new domain and that the login names are the same as on the current domain.
  2. Stop all services and application pools that concerns Team Foundation Server.
  3. Move the servers to the new domain.
  4. Use TFSAdminUtil to change service accounts and update user accounts.
  5. Start all services and application pools again.
The move went absolutely perfect and I could connect with he server on the new domain on the first try. There were some small issues with the SharePoint configuration since the SharePoint service account was not changed. Luckily there is a tool for that:

stsadm.exe -o updatefarmcredentials -userlogin DOMAIN\user -password ******

Comments

Popular posts from this blog

Binding a HTML-formatted string to a WPF WebBrowser control

Sometimes there is a need to display a HTML formatted string in a WPF application. There are a couple of ways to do this, but the most stright forward is to use a WebBrowser control and the NavigateToString method. This approach has one big flaw, you cannot use binding to a string out of the box, but I found a great solution through Stack Overflow which adds a bindable property to the  WebBrowser  control using  NavigateToString . The following class is all that is needed to add that behavior. A new depencency property named Html is introduced to the  WebBrowser  and the proper change action is performed in the OnHtmlChanged method. public class BrowserBehavior { public static readonly DependencyProperty HtmlProperty = DependencyProperty.RegisterAttached( "Html", typeof(string), typeof(BrowserBehavior), new FrameworkPropertyMetadata(OnHtmlChanged)); [AttachedPropertyBrowsableForType(typeof(WebBrowser))] public static string GetHtml(WebBrowser bro

User.Identity returns old login name after name change

When a person gets married or makes a name change for some other reason this usually means that the login name for the Active Directory-account changes as well. This is rarely a problem, but it turned out to cause some issues on our web server, where the  User.Identity  property was still returning the old login name. The user logged on with the new login name, but was identified by the web application as the old login name. The reason this occurs is because the  User.Identity  property relies on the  LsaLookupSids  method to convert the user SID to a login name. The method first calls the local  LSA-cache , which is not synchronized with the Active Directory. For this purpose a simple reboot of the web server to clear the  LSA-cache  propably would have sufficed. But since we didn't want to take the application offline rebooting was not an option. Instead, it is possible to set the registry value  LsaLookupCacheMaxSize in HKLM\SYSTEM\CurrentControlSet\Control\Lsa. If this val

Using Bootstrap Tooltip to show Parsley validation errors

I'm currently working on a web application using a variety of different frameworks, such as Backbone for the back-end, Bootstrap for the front-end and Parsley for client side form validation.  Parsley is a really powerful validation toolkit, but it takes some tweaking to make it blend with the Bootstrap front-end. Fortunately this is a one time fix, which can be re-used all over our project. Since there will be some custom options in our  Parsley  object, we can't use the default parsley-validate attribute on the form. Instead we have to initialize the validation with the jQuery syntax: $('#my-form').parsley(parsleyOptions); The options are were the magic happens, and in our case we have a global options object that our forms use to get the same experience all over the application. Here's what it looks like: var parsleyOptions = {  // Sets success and error class to Bootstrap class names  successClass: 'has-success',  errorClass: 'has-er