Skip to main content

Posts

Showing posts from August, 2011

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 value is set to 0 …

Windows Server 2008 R2 DNS issues

This week we stumbled upon some weirdness in our new 2008 R2 DNS servers. A couple of URLs, for example www.smhi.se and www.stockholm.se could not be resolved from a 2008 R2 server. The existing 2003 servers with the same configuration worked perfectly.

After thorough troubleshooting we found out that there is a new default setting in Windows Server 2008 R2 regarding the EDNS-protocol that caused the issues. Not all of the DNS servers around the internet are able to handle EDNS, but in 2008 R2 this protocol is enabled by default. Normally you would think there is a fallback mechanism to standard DNS protocol if an EDNS request fails, but Windows Server does not have that.

The solution was simply to disable EDNS by using the command: dnscmd /config /EnableEDNSProbes 0

Scott Forsyth has written more about this issue and how he found the solution:
http://weblogs.asp.net/owscott/archive/2009/09/15/windows-server-2008-r2-dns-issues.aspx

Configure static ports for Exchange

In a firewalled Exchange environment it is always easier if Exchange communicates on static ports. Normally RPC on port 135 is used to initialize the communication. Any further communication is made through a port dynamically selected by each service on the Exchange-server.

I will not go deeper into how this is made, because it has been described very well in this blog:
http://www.proexchange.be/blogs/exchange2007/archive/2009/05/18/configuring-static-ports-for-exchange-2007.aspx

Except from the traditional bribes to the network guys, there were just a couple of registry settings on the Exchange-server and some of the clients to make everything work as a charm, even through the firewalls.