Remote desktop connections remain active until the logged in user selects "Log Off" from the Start Menu. If a user closes the remote desktop window without logging off, the user will still remain logged on.

Only up to two simultaneous Remote Desktop connections are allowed by default and active and disconnected sessions are calculated in this connection limit.

If a third simultaneous attempt is made to login to the server "The terminal server has exceeded the maximum number of allowed connections" error will be shown to the user, and they will be unable to complete the login process.

More...

After taking a web application online, you need to track exceptions and errors effectively in order to debug problems. ELMAH (Error Logging Modules and Handlers) is an application wide error logging facility which is completely pluggable therefore it can be added to a running ASP.NET web application without any need for compilation or deployment.

HTTP modules and handlers can be used in ASP.NET to provide a high degree of componentization for code that is orthogonal to a web application, enabling entire sets of functionalities to be developed, packaged and deployed as a single unit and independent of an application. ELMAH (Error Logging Modules and Handlers) illustrates this approach by demonstration of an application-wide error logging that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.

Elmah Project Site

Elmah logs nearly all unhandled exceptions. It offers web pages to remotely view the exception log and its details. Even if customErrors mode in web.config file is turned off, you can view the yellow error screen. It offers notifications via e-mail and an RSS feed of the error log. 

To learn more about ELMAH, see the MSDN article Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components by Scott Mitchell and Atif Aziz.

After Migrating the application to work with the Integrated .NET mode, you might come across a problem: Server Error in Application "WebSiteName" - HTTP Error 401.3 – Unauthorized 

Click on Authentication and click edit after choosing Anonymous Authentication. In the opening window select Application Pool identity and click OK.

 

You might have come across to the following “HTTP Error 500.0 - Internal Server Error” while working on Windows Vista. 

Follow the directions shown on the error message to resolve the problem:

You can migrate the application configuration, including the contents of the configuration section, by using the following from a command line window (the window must be running as Administrator):

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "bloggingdeveloper/"

1) Migrate the application to work with the Integrated .NET mode (PREFERRED).

You can migrate the application configuration, including the contents of the configuration section, by using the following from a command line window (the window must be running as Administrator):

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "bloggingdeveloper/"

After you migrate your application, it will run in both Classic and Integrated .NET modes, as well as on downlevel platforms.

2) Move this application to an application pool using the Classic .NET mode.

You can move the application to the default application pool using the Classic .NET mode by running the following from an command line window (the window must be running as Administrator):

%systemroot%\system32\inetsrv\APPCMD.EXE set app "bloggingdeveloper/" /applicationPool:"Classic .NET AppPool"

Alternatively, you can use any other application pool on your system that is running in the Classic .NET mode. You can also use the IIS Administration tool to move this application to another application pool.

You might have come across to the following “HTTP Error 500.19 - Internal Server Error” while trying to create IIS 7.0 web site on Windows Vista. Actually Microsoft has tightened the security on Windows Vista and most of the time it is annoying when it asks your permission. 

To resolve this problem:

Compile the project and place the deployable files under C:\Inetpub\wwwroot\. Make sure that the physical path of the respective Application (e.g. BloggingDeveloper in above error case) under IIS now points to new path.

OR

Browse your application root folder and add group IIS_IUSRs.

 

When building ASP.NET website with Visual Studio 2008 Beta 2 or Visual Web Developer 2008 Express, a new entry in the applications web.config configuration file is inserted. This is done when the user creates a new project, or migrates an existing website to use .NET Framework 3.5.

An example of the configuration entry is given below:

<system.codedom>
   <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
         type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
         warningLevel="4" compilerOptions="/warnaserror-">
      <providerOption name="CompilerVersion" value="v3.5"/>
      </compiler>
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
         type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
         compilerOptions="/optioninfer+">
      <providerOption name="CompilerVersion" value="v3.5"/>
      </compiler>
   </compilers>
</system.codedom>

Since The compilerOptions setting is not allowed in medium trust or a partial trust, when this website runs in medium trust or any partial trust setting, ASP.NET will raise the following error

“the current trust level does not allow use of the ‘compilerOptions’ attribute”.

Solution 1:

To solve the problem, you have to remove the compilerOptions setting and the warningLevel setting, from configuration section in web.config file after creating or migrating the application. After the change, the settings should appear as follows:

<system.codedom>
   <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
         type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5"/>
      </compiler>
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
         type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5"/>
      </compiler>
   </compilers>
</system.codedom>

Solution 2:

To solve the problem open the web.config file and add/change the trust level as follows:

<system.web>   
   <trust level="Full"/>
</system.web>

Finally, rebuild the project.

When trying to install Adobe Photoshop CS3, Adobe Flash CS3, Adobe Fireworks CS3, Adobe Dreamweaver CS3, Adobe Creative Suite 3 Web Premium, Adobe Creative Suite Production Premium on Windows Vista 32-bit or Windows Vista 64-bit, you may come across the following error:

Setup has encountered an error and cannot continue. Contact Adobe Customer Support for assistance.

Internal Error 2739.

The Internal Error 2739 problem can be solved by registering the JScript.dll and VBScript.dll modules in Windows Vista. 

Step by Step Solution

1. Run command prompt as Administrator
2. Change folder by issuing the following command :

                For Windows Vista 32-bit: cd C:\windows\System32
                For Windows Vista 64-bit: cd C:\windows\SysWow64

3. Type the following command and hit Enter:

                regsvr32 jscript.dll

4. Type the following command and hit Enter:

                regsvr32 vbscript.dll

5. Run the installer again.
   

If you skip step 1 and do not run the command prompt as administrator you will get the following error when registering the script modules.

The module "jscript.dll" was loaded but the call to DllRegisterServer failed with error code 0x80004005.

For more information about this problem, search online using the error code as a search term.