When migrating an application from Windows 2003 to Windows 2008, the major concerns are around migrating from IIS 6 to IIS 7.
For Classic ASP applications, the settings can be taken from Moving asp Web site from IIS 6 to IIS 7.5 on Windows 2008 R2:
- Configure the App Pool ".Net Framework version" to use "No Managed Code"
- Set the "Managed pipeline mode" to "Classic"
- Set "Enable 32 bit Applications" to true, in the "Advanced Settings"
- Set the "Identity" to "Network Service", in the "Advanced Settings"
In case of errors, to help debugging you can temporarily enable:
- In “Debugging Properties”, set "Send Errors to Browser" to True
- In Internet Explorer, in “Internet Options” turn off “Show friendly HTTP error messages”
For .NET applications, the considerations are:
The installation of SQL Server requires .NET Framework 3.5.1.
- Maintain the Application Pool in the old Classic Mode, or convert it to the new Integrated Mode
The process is impacted above all if HttpModules and HttpHandlers are used, and the process is described in Moving an ASP.NET Application from IIS 6.0 to IIS 7.0.
In addition, the automated tool "APPCMD.EXE migrate config " can bed used. It is described in ASP.NET Integration with IIS 7.
- If you are moving from an original 32 bit to 64 bit environments:
- if the application is compiled for 32 bit mode, it is enough to set "Enable 32-Bit Applications" property to true in the Application Pool settings
- If it is compiled for "Any CPU" you may want to try to run in in 64 bit mode. If it has not dependencies on 32 bit resources (i.e. assemblies deployed in the 32 bit GAC), it should run without any problem
- If it is compiled for "Any CPU" and you need to run it in 32 bit mode on a 64 bit system, you can try to force its "bit-ness" using the CorFlags utility. The only risk is that this solution changes the assembly header, so it is not applicable with signed assemblies
- If it is compiled for "Any CPU" and you need to run it in 32 bit mode on a 64 bit system and the assembly is digitally signed, you need to recompile the sources. Here you have two latest choices:
- recompile forcing 32 bit mode
- or better remove the dependency on the 32 bit resource so that the application can be run in 64 bit
Installing this framework on Windows 2012 (both standard and R2) is not easy, there is something wrong with the setup.
By default, Windows 2008 disables multiple RDP connections with the same user.
But you can enable them in this way: start up gpedit.msc, go to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections\, find "Restrict each user to a single session" and disable. You can find more details in the post Enable Multiple Remote Desktop Connections in Window Server 2008.
Of course, if you're on a domain and want to apply it to multiple machines, you obviously need to make it a domain policy.
But if you have installed Terminal Services, please follow the guide in the article Enable Multiple Remote Desktop Sessions on Server 2008.
Are you a consultant in a company, need to read/write the ActiveDirectory of your client, but you are usign your own laptop, witch is outside the domian?
I have found a solution to run the dsa.msc applet running in a computer outside the domain:
runas /netonly /user:DOMAIN\USER "mmc dsa.msc /domain=FQN_DOMAIN"
Kerberos is used when you have Windows authentication with impersonification and the impersonated user needs to access resources outside the web server.
For example, you can use it when from your SharePoint server you need to access an Exchange web-service to get the user mail and calendar.
To enable Kerberos authentication, you need to complete the following tasks:
- From the Central Administration, change the web-application settings to use Kerberos (negotiate) authentication insted of NTLM authentication
- To add the SPNs for the web-server, from a command line prompt, execute:
- setspn -a HTTP/ServerName Domain\ServerName
- setspn -a HTTP/ServerName.Domain Domain\ServerName
- To add the SPNs for the application pool user, from a command line prompt, execute:
- setspn -a HTTP/ServerName Domain\User
- setspn -a HTTP/ServerName.Domain Domain\User
- Finally, from the Active Directory Users and Computer, check the application pool user as trusted for delegation.
More details in the article How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication.