I also have some reference information for you.
1. I also found post that say the problem appeared after “reformat” the server. It looks similar to our case. Maybe can give you a hint.
http://www.velocityreviews.com/forums/t81921-forms-auth-cookie-vanishes-immediately-after-login.html
How about just remove the site and create new one with different name/description? Sometime it works.
2. The problem does not appear on FireFox that means there should be no problem with the connection between Web server and SQLServer session. It means the problem is the Authentication Cookie lost problem. We need to find out where the cookies lost (server/client).
Here is the tool (free) that can help to check the header information (include cookie) sent between browser and web server.
http://www.fiddler2.com/Fiddler2/version.asp
Here is the Microsoft Help and Desk information on cookie lost.
http://support.microsoft.com/kb/910439
3. I also checked related source code in Australia project, the only suspicious place is the “User” property of UIBase. But I don’t think it will affect “HttpContext.Current.User”. If you think it is necessary, I can change it to use something else like “Actor”. It will involve changes in almost all pages in Web project.
Agile Modules blog is a place to announce and discuss about agile modules provided Addons-Modules.com - a developer of modules and addons for PrestaShop shopping cart systems. Our market place solution - Agile Multiple Sellers/Vendors Module - and its accessory modules are quite simply the best solution to build marketplace based on PrestaShop. These modules have helped many of our clients realize their dream of starting, managing, and generating profits from their own online marketplace.
Wednesday, June 25, 2008
Reseeding the identity value:
Reseeding the identity value
You can reseed the indentity value, that is, to have the identity values reset or start at a new predefined value by using DBCC CHECKIDENT. For example, if I have a table named MYTABLE and I want to reseed the indentity column to 30 I would execute the following:
dbcc checkident (mytable, reseed, 30)
If you wanted to reseed the table to start with an identity of 1 with the next insert then you would reseed the table's identity to 0. The identity seed is what the value is currently at, meaning that the next value will increment the seed and use that. However, one thing to keep in mind is that if you set the identity seed below values that you currently have in the table, that you will violate the indentity column's uniqueness constraint as soon as the values start to overlap. The identity value will not just “skip” values that already exist in the table
You can reseed the indentity value, that is, to have the identity values reset or start at a new predefined value by using DBCC CHECKIDENT. For example, if I have a table named MYTABLE and I want to reseed the indentity column to 30 I would execute the following:
dbcc checkident (mytable, reseed, 30)
If you wanted to reseed the table to start with an identity of 1 with the next insert then you would reseed the table's identity to 0. The identity seed is what the value is currently at, meaning that the next value will increment the seed and use that. However, one thing to keep in mind is that if you set the identity seed below values that you currently have in the table, that you will violate the indentity column's uniqueness constraint as soon as the values start to overlap. The identity value will not just “skip” values that already exist in the table
Monday, June 23, 2008
Visual SourceSafe 2005 Internet and IIS Setup
http://diaryproducts.net/about/operating_systems/windows/sourcesafe_2005_internet_iis
One might think that it wouldn't be so difficult to setup Visual SourceSafe 2005 on Windows Server 2003 with IIS such that users can access the SourceSafe database using the Visual SourceSafe 2005 Internet plugin. But dude, I was so wrong! I managed to get it working in the end but it took me an etire day. Anyway, this isn't a complete HowTo. I would just like to point out a few not so obvious caveats.
First, Alin Constantin's Installing and configuring Microsoft Visual SourceSafe for Internet (Remote) access is a good introduction to these matters except that he suggests using an account with administrative priviledges to access SourceSafe. That's something I wouldn't do. Instead, follow Microsoft's Securing a Database. There is also Microsoft's How to: Enable Remote Access Manually which might help in case you're running one of the new 64-bit releases of Windows.
Before attempting any of the above procedures, you should make sure that
the Default website is running. SourceSafe Internet is a ASP.Net web-application that needs to be setup properly. The SourceSafe Administrator tool can do that for you but only for the default website. The default website's default name is Default ;-). In case someone renamed the database it can also be identified by having an ID of 1. I strongly recommend using the SourceSafe Administrator to configure the web application because doing it manually is a pain in the - you know where.
if the URLScan utility is installed, the PUT verb is allowed. The last section of How to: Enable Remote Access Manually tells you how. In a nutshell, move the line PUT from section [DenyVerbs] to section [AllowVerbs] and restart IIS. Otherwise uploads won't work.
I saved the most important hint for the end of this post. After SourceSafe Administrator is finished configuring the web application, you need to enable the script mapping for the .asmx extension. I don't know why this isn't done automatically but hey, we love those little challenges, don't we.
Go to Internet Information Service (IIS) Manager, right-click the SourceSafe virtual directory and select Properties.
In the Virtual Directory tab click Configuration.
Under Application extension, find the entry for .aspx and click edit. Copy the name of the executable and click Cancel.
Back in the Application Configuration dialog, click Add.
Paste the executable name into Executable and type .asmx into Extension. Select All verbs, check Script engine and uncheck Verify that file exists.
Click OK.
Click OK.
I spent the majority of a work day to figure this out. I had to run a network sniffer because Microsoft's error messages are as informative as "The server returned 0x80004005" and a dubious "404 File Not Found" for soemthing completely unrelated.
Oh, another thing: SourceSafe Administrator puts the SourceSafe Internet web application in the default application pool. SourceSafe Internet is a ASP.Net 2.X application. If there is an ASP.Net 1.X application in the same pool, either this or the SourceSafe Internet application will stop. To resolve this, put them in separate application pools or switch the 1.X app to 2.X.
One might think that it wouldn't be so difficult to setup Visual SourceSafe 2005 on Windows Server 2003 with IIS such that users can access the SourceSafe database using the Visual SourceSafe 2005 Internet plugin. But dude, I was so wrong! I managed to get it working in the end but it took me an etire day. Anyway, this isn't a complete HowTo. I would just like to point out a few not so obvious caveats.
First, Alin Constantin's Installing and configuring Microsoft Visual SourceSafe for Internet (Remote) access is a good introduction to these matters except that he suggests using an account with administrative priviledges to access SourceSafe. That's something I wouldn't do. Instead, follow Microsoft's Securing a Database. There is also Microsoft's How to: Enable Remote Access Manually which might help in case you're running one of the new 64-bit releases of Windows.
Before attempting any of the above procedures, you should make sure that
the Default website is running. SourceSafe Internet is a ASP.Net web-application that needs to be setup properly. The SourceSafe Administrator tool can do that for you but only for the default website. The default website's default name is Default ;-). In case someone renamed the database it can also be identified by having an ID of 1. I strongly recommend using the SourceSafe Administrator to configure the web application because doing it manually is a pain in the - you know where.
if the URLScan utility is installed, the PUT verb is allowed. The last section of How to: Enable Remote Access Manually tells you how. In a nutshell, move the line PUT from section [DenyVerbs] to section [AllowVerbs] and restart IIS. Otherwise uploads won't work.
I saved the most important hint for the end of this post. After SourceSafe Administrator is finished configuring the web application, you need to enable the script mapping for the .asmx extension. I don't know why this isn't done automatically but hey, we love those little challenges, don't we.
Go to Internet Information Service (IIS) Manager, right-click the SourceSafe virtual directory and select Properties.
In the Virtual Directory tab click Configuration.
Under Application extension, find the entry for .aspx and click edit. Copy the name of the executable and click Cancel.
Back in the Application Configuration dialog, click Add.
Paste the executable name into Executable and type .asmx into Extension. Select All verbs, check Script engine and uncheck Verify that file exists.
Click OK.
Click OK.
I spent the majority of a work day to figure this out. I had to run a network sniffer because Microsoft's error messages are as informative as "The server returned 0x80004005" and a dubious "404 File Not Found" for soemthing completely unrelated.
Oh, another thing: SourceSafe Administrator puts the SourceSafe Internet web application in the default application pool. SourceSafe Internet is a ASP.Net 2.X application. If there is an ASP.Net 1.X application in the same pool, either this or the SourceSafe Internet application will stop. To resolve this, put them in separate application pools or switch the 1.X app to 2.X.
Saturday, June 21, 2008
How can I install Remote Desktop Web Connection on Windows Server 2003?
How can I install Remote Desktop Web Connection on Windows Server 2003?
http://www.petri.co.il/install_remote_desktp_web_connection_on_windows_server_2003.htm
Remote Desktop Web Connection is an optional World Wide Web Service component of Internet Information Services, which is included by default in Windows XP Professional, Windows 2000 and Windows Server 2003. Just like IIS, Remote Desktop Web Connection is not installed by default on Windows XP/2003, but must be installed using Add or Remove Programs.
A Must for Mastering Windows Vista - Watch These Videos!
I just finished watching the Windows Vista Training videos by Train Signal and I highly recommend this course, as you will learn much more than you will from books (which never seem to have enough detail!). Their learn by doing approach is excellent because it shows you the "ins and outs" of Vista instead of reading pages and pages of theory.
Daniel Petri, Petri IT Knowledge Base
Click Here to Watch the Windows Vista Videos!
The Remote Desktop Web Connection is an optional component of Windows Server 2003 and can be installed from the installation media.
Note: Users of Windows Server 2003 do not need to download this package. They can manually add this package from Add/Remove in the Control Panel. However, if you still want to download the package please read Download Remote Desktop Web Connection for Windows Server 2003.
When you install Remote Desktop Web Connection, the files are copied by default to the %systemroot%\Web\Tsweb directory of your webserver. The included sample default.htm and connect.asp page can be used as is, or you can modify them to meet the needs of your application.
The Remote Desktop Web Connection is a Win32-based ActiveX control (COM object) that can be used to run Remote Desktop sessions from within Internet Explorer.
The Remote Desktop Web Connection download package includes the downloadable ActiveX control and sample Web page that can be used as a starting point for running Windows-based programs inside Internet Explorer. Developers can also use the Remote Desktop Web Connection to develop client-side applications that interact with applications running on a terminal server.
The downloadable ActiveX control provides most of the same functionality as the full Remote Desktop Connection software in Windows Server 2003 (read Download RDP 5.2), but is designed to deliver this functionality over the Web. The Web Package Setup program installs the downloadable ActiveX control, the ActiveX Client Control Deployment Guide, and sample Web pages on a server running Internet Information Services 4.0 or later.
Remote Desktop Web Connection benefits include:
Run sessions within Internet Explorer - The Remote Desktop Web Connection is a Win32 ActiveX control that runs in Internet Explorer 5 and later versions—on any Windows 32-bit operating system. When users first navigate to a Web page embedded with the Remote Desktop Web Connection ActiveX control, they will see a dialog box that asks, "Do you want to install this control?" Using the sample Web pages as an example, the Web site administrator can design pages that either link directly to a terminal server-hosted application, or simply run the entire desktop.
Quick and easy access to computers running Windows XP Professional with Remote Desktop enabled or Windows Terminal Servers - The Remote Desktop Web Connection is especially useful for fast, on-demand access to terminal servers by both users and administrators.
Ability to be embedded in Web pages or launched in separate pages - Using the functionality of Internet Explorer, Remote Desktop sessions can be embedded in an existing Web page, or launched in a separate Internet Explorer window. A Web site administrator can create simple scripting code that allows users to launch multiple Remote Desktop sessions from the same Web page, or start multiple Remote Desktop sessions within a single Web page.
Programmability - As with any ActiveX control or COM object, many applications such as Internet Explorer or Visual Basic, and Visual C++ development systems can insert and set properties on the Remote Desktop Web Connection. The Web site author or programmer can write scripts that communicate between an application running on the desktop and a Terminal Services-hosted application using the Remote Desktop Web Connection and the Remote Desktop Protocol virtual channel architecture.
Remote Desktop Web Connection Security - The Remote Desktop Web Connection is a high-encryption, Remote Desktop Protocol (RDP) 5.0 client and uses RSA Security’s RC4 cipher with a key strength of 40-, 56-, or 128-bit, as determined by the server to which it is connecting. The Remote Desktop Web Connection uses the well-known RDP TCP port (3389) to communicate to the server. Unlike some other display protocols, which send data over the network using clear text or with an easily decodable "scrambling" algorithm, Remote Desktop Web Connection's built-in encryption makes it safe to use over any network - including the Internet - as the protocol cannot be easily sniffed to discover passwords and other sensitive data.
To install Remote Desktop Web Connection
Open Add or Remove Programs in Control Panel.
Click Add/Remove Windows Components.
Select Internet Information Services, and then click Details.
In the Subcomponents of Internet Information Services list, select World Wide Web Service, and then click Details.
In the Subcomponents for World Wide Web Service list, click the Remote Desktop Web Connection check box, and then click OK.
In the Windows Components Wizard, click Next.
Open Internet Services Manager.
Expand the folder hierarchy until you reach the local computer name\Web Sites\Default Web Site\tsweb folder.
Right-click the tsweb folder and then click Properties.
Click the Directory Security tab on the Properties dialog box.
In Anonymous access and authentication control, click Edit.
Check the Anonymous access check box on the Authentication Methods dialog box, and then click OK twice.
To connect to another computer using Remote Desktop Web Connection
Ensure that Remote Desktop Web Connection is installed and running on the Web server.
Ensure that your client computer has an active network connection and that the WINS server service (or other name resolution method) is functioning.
On your client computer, start Microsoft Internet Explorer.
In the Address box, type the Uniform Resource Locator (URL) for the home directory of the Web server hosting Remote Desktop Web Connection.
The URL is "http://" followed by the Windows Networking name of your server, followed by the path of the directory containing the Remote Desktop Web Connection files (default = /Tsweb/). (Note the forward slash marks.) For example, if your Web server is registered with the WINS server as "Admin1", in the Address box you type: http://admin1/tsweb/, and then press ENTER. The Remote Desktop Web Connection page appears on the screen.
In Server, type the name of the remote computer to which you want to connect.
Optionally, specify the screen size and logon information for your connection.
Click Connect.
After you supply your username and password the Windows Server 2003 desktop appears and you can begin to work.
http://www.petri.co.il/install_remote_desktp_web_connection_on_windows_server_2003.htm
Remote Desktop Web Connection is an optional World Wide Web Service component of Internet Information Services, which is included by default in Windows XP Professional, Windows 2000 and Windows Server 2003. Just like IIS, Remote Desktop Web Connection is not installed by default on Windows XP/2003, but must be installed using Add or Remove Programs.
A Must for Mastering Windows Vista - Watch These Videos!
I just finished watching the Windows Vista Training videos by Train Signal and I highly recommend this course, as you will learn much more than you will from books (which never seem to have enough detail!). Their learn by doing approach is excellent because it shows you the "ins and outs" of Vista instead of reading pages and pages of theory.
Daniel Petri, Petri IT Knowledge Base
Click Here to Watch the Windows Vista Videos!
The Remote Desktop Web Connection is an optional component of Windows Server 2003 and can be installed from the installation media.
Note: Users of Windows Server 2003 do not need to download this package. They can manually add this package from Add/Remove in the Control Panel. However, if you still want to download the package please read Download Remote Desktop Web Connection for Windows Server 2003.
When you install Remote Desktop Web Connection, the files are copied by default to the %systemroot%\Web\Tsweb directory of your webserver. The included sample default.htm and connect.asp page can be used as is, or you can modify them to meet the needs of your application.
The Remote Desktop Web Connection is a Win32-based ActiveX control (COM object) that can be used to run Remote Desktop sessions from within Internet Explorer.
The Remote Desktop Web Connection download package includes the downloadable ActiveX control and sample Web page that can be used as a starting point for running Windows-based programs inside Internet Explorer. Developers can also use the Remote Desktop Web Connection to develop client-side applications that interact with applications running on a terminal server.
The downloadable ActiveX control provides most of the same functionality as the full Remote Desktop Connection software in Windows Server 2003 (read Download RDP 5.2), but is designed to deliver this functionality over the Web. The Web Package Setup program installs the downloadable ActiveX control, the ActiveX Client Control Deployment Guide, and sample Web pages on a server running Internet Information Services 4.0 or later.
Remote Desktop Web Connection benefits include:
Run sessions within Internet Explorer - The Remote Desktop Web Connection is a Win32 ActiveX control that runs in Internet Explorer 5 and later versions—on any Windows 32-bit operating system. When users first navigate to a Web page embedded with the Remote Desktop Web Connection ActiveX control, they will see a dialog box that asks, "Do you want to install this control?" Using the sample Web pages as an example, the Web site administrator can design pages that either link directly to a terminal server-hosted application, or simply run the entire desktop.
Quick and easy access to computers running Windows XP Professional with Remote Desktop enabled or Windows Terminal Servers - The Remote Desktop Web Connection is especially useful for fast, on-demand access to terminal servers by both users and administrators.
Ability to be embedded in Web pages or launched in separate pages - Using the functionality of Internet Explorer, Remote Desktop sessions can be embedded in an existing Web page, or launched in a separate Internet Explorer window. A Web site administrator can create simple scripting code that allows users to launch multiple Remote Desktop sessions from the same Web page, or start multiple Remote Desktop sessions within a single Web page.
Programmability - As with any ActiveX control or COM object, many applications such as Internet Explorer or Visual Basic, and Visual C++ development systems can insert and set properties on the Remote Desktop Web Connection. The Web site author or programmer can write scripts that communicate between an application running on the desktop and a Terminal Services-hosted application using the Remote Desktop Web Connection and the Remote Desktop Protocol virtual channel architecture.
Remote Desktop Web Connection Security - The Remote Desktop Web Connection is a high-encryption, Remote Desktop Protocol (RDP) 5.0 client and uses RSA Security’s RC4 cipher with a key strength of 40-, 56-, or 128-bit, as determined by the server to which it is connecting. The Remote Desktop Web Connection uses the well-known RDP TCP port (3389) to communicate to the server. Unlike some other display protocols, which send data over the network using clear text or with an easily decodable "scrambling" algorithm, Remote Desktop Web Connection's built-in encryption makes it safe to use over any network - including the Internet - as the protocol cannot be easily sniffed to discover passwords and other sensitive data.
To install Remote Desktop Web Connection
Open Add or Remove Programs in Control Panel.
Click Add/Remove Windows Components.
Select Internet Information Services, and then click Details.
In the Subcomponents of Internet Information Services list, select World Wide Web Service, and then click Details.
In the Subcomponents for World Wide Web Service list, click the Remote Desktop Web Connection check box, and then click OK.
In the Windows Components Wizard, click Next.
Open Internet Services Manager.
Expand the folder hierarchy until you reach the local computer name\Web Sites\Default Web Site\tsweb folder.
Right-click the tsweb folder and then click Properties.
Click the Directory Security tab on the Properties dialog box.
In Anonymous access and authentication control, click Edit.
Check the Anonymous access check box on the Authentication Methods dialog box, and then click OK twice.
To connect to another computer using Remote Desktop Web Connection
Ensure that Remote Desktop Web Connection is installed and running on the Web server.
Ensure that your client computer has an active network connection and that the WINS server service (or other name resolution method) is functioning.
On your client computer, start Microsoft Internet Explorer.
In the Address box, type the Uniform Resource Locator (URL) for the home directory of the Web server hosting Remote Desktop Web Connection.
The URL is "http://" followed by the Windows Networking name of your server, followed by the path of the directory containing the Remote Desktop Web Connection files (default = /Tsweb/). (Note the forward slash marks.) For example, if your Web server is registered with the WINS server as "Admin1", in the Address box you type: http://admin1/tsweb/, and then press ENTER. The Remote Desktop Web Connection page appears on the screen.
In Server, type the name of the remote computer to which you want to connect.
Optionally, specify the screen size and logon information for your connection.
Click Connect.
After you supply your username and password the Windows Server 2003 desktop appears and you can begin to work.
Monday, June 16, 2008
VS 2005, Web Site Project/Web Application Project
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
The Web Application Projects add-in provides a Visual Studio 2005 Web project model option that works like the Visual Studio .NET 2003 Web project model. In this paper, the new project type is referred to as a Web application project. You can use Web application projects as an alternative to the Web site project model already available in Visual Studio 2005, which we refer to in this paper as Web site projects.
Purpose of Web Application Projects
The goal of Web application projects is to address some of the feedback we have heard from customers. Some developers find migrating Visual Studio .NET 2003 applications to the new Web site model in Visual Studio 2005 impractical, especially because precompiling (publishing) a Visual Studio 2005 Web site creates multiple assemblies.
The new Web application project type also enables some scenarios where Visual Studio 2005 Web projects are different than in the previous version of Visual Studio. For example, the new model has different semantics for Web subprojects where the subproject is not an ASP.NET or IIS application, but instead feeds its generated assembly to a parent application's Bin folder.
The new project type also provides a model that will feel familiar to developers who do not want to change how they structure their Web projects from how they use Visual Studio .NET 2003 today—for example, they want to continue to use a project file.
The new Web application project type does not replace the Web site project type introduced in Visual Studio 2005, which provides many new features and additional flexibility in how you manage Web applications. Instead, it is an alternative project type that you might choose depending on your requirements and your preferred development workflow. Some developers will find the default Visual Studio 2005 Web site project model natural and easy to use. Other developers will prefer a model in which project resources are defined explicitly (rather than implicitly by simply being in a folder) and in which they have tighter control over their project, and will therefore choose the new Web application project model. Rather than forcing developers to use just one project model, we will support both project models and allow developers to choose whichever Web project model works best for them.
The Web Application Projects add-in provides a Visual Studio 2005 Web project model option that works like the Visual Studio .NET 2003 Web project model. In this paper, the new project type is referred to as a Web application project. You can use Web application projects as an alternative to the Web site project model already available in Visual Studio 2005, which we refer to in this paper as Web site projects.
Purpose of Web Application Projects
The goal of Web application projects is to address some of the feedback we have heard from customers. Some developers find migrating Visual Studio .NET 2003 applications to the new Web site model in Visual Studio 2005 impractical, especially because precompiling (publishing) a Visual Studio 2005 Web site creates multiple assemblies.
The new Web application project type also enables some scenarios where Visual Studio 2005 Web projects are different than in the previous version of Visual Studio. For example, the new model has different semantics for Web subprojects where the subproject is not an ASP.NET or IIS application, but instead feeds its generated assembly to a parent application's Bin folder.
The new project type also provides a model that will feel familiar to developers who do not want to change how they structure their Web projects from how they use Visual Studio .NET 2003 today—for example, they want to continue to use a project file.
The new Web application project type does not replace the Web site project type introduced in Visual Studio 2005, which provides many new features and additional flexibility in how you manage Web applications. Instead, it is an alternative project type that you might choose depending on your requirements and your preferred development workflow. Some developers will find the default Visual Studio 2005 Web site project model natural and easy to use. Other developers will prefer a model in which project resources are defined explicitly (rather than implicitly by simply being in a folder) and in which they have tighter control over their project, and will therefore choose the new Web application project model. Rather than forcing developers to use just one project model, we will support both project models and allow developers to choose whichever Web project model works best for them.
Saturday, June 14, 2008
Terminal Services in remote administration mode -- 2003
It is no longer necessary to install Terminal Services in Remote Administration mode (now called Remote Desktop for Administration). When you install one of the Windows Server 2003 family operating systems, Remote Desktop for Administration is installed automatically. To use Remote Desktop for Administration, you must first enable remote connections. For more information
To enable or disable Remote Desktop
Using Group Policies (best practice)
1.
Open Group Policy.
2.
In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, double-click the Allows users to connect remotely using Terminal Services setting.
3.
Do one of the following:
• To enable Remote Desktop, click Enabled.
• To disable Remote Desktop, click Disabled.
If you disable Remote Desktop while users are connected to the target computers, the computers maintain their current connections, but will not accept any new incoming connections.
Important
When you enable Remote Desktop on a computer, you enable the capability for other users and groups to log on remotely to the computer. However, you must also decide which users and groups should be able to log on remotely, and then manually add them to the Remote Desktop Users group. For more information, see Enabling users to connect remotely to the server and Add users to the Remote Desktop Users group.
You should thoroughly test any changes you make to group Policy settings before applying them to users or computers. Fore more information about testing policy settings, see Resultant Set of Policy
Note
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
• Use the above procedure to configure the local Group Policy object. To change a policy for a domain or an organizational unit, you must log on to the primary domain controller as an administrator. Then, you must start Group Policy by using the Active Directory Users and Computers snap-in.
• If the Allows users to connect remotely using Terminal Services Group Policy setting is set to Not Configured, the Enable Remote Desktop on this computer setting (on the Remote tab of the System Properties dialog box) on the target computers takes precedence. Otherwise, the Allows users to connect remotely using Terminal Services Group Policy setting takes precedence.
• Be aware of the security implications of remote logons. Users who log on remotely can perform tasks as though they were sitting at the console. For this reason, you should ensure that the server is behind a firewall. For more information, see VPN servers and firewall configuration and Security information for IPSec.
• You should require all users who make remote connections to use a strong password. For more information, see Strong passwords.
• Remote Desktop is disabled by default in Windows Server 2003 operating systems.
Using System Properties
1.
Open System in Control Panel.
2.
On the Remote tab, select or clear the Enable Remote Desktop on this computer check box, and then click OK.
Important
When you enable Remote Desktop on a computer, you enable the capability for other users and groups to log on remotely to the computer. However, you must also decide which users and groups should be able to log on remotely, and then manually add them to the Remote Desktop Users group. For more information, see Enabling users to connect remotely to the server and Add users to the Remote Desktop Users group.
Note
• You must be logged on as a member of the Administrators group to enable or disable Remote Desktop.
• To open a Control Panel item, click Start, click Control Panel, and then double-click the appropriate icon.
• Any configuration set with Group Policy overrides the configuration set by using System properties, as described in this procedure.
• Be aware of the security implications of remote logons. Users who log on remotely can perform tasks as though they were sitting at the console. For this reason, you should ensure that the server is behind a firewall. For more information, see VPN servers and firewall configuration and Security information for IPSec.
• You should require all users who make remote connections to use a strong password. For more information, see Strong passwords.
• Remote Desktop is disabled by default in Windows Server 2003 operating systems.
To enable or disable Remote Desktop
Using Group Policies (best practice)
1.
Open Group Policy.
2.
In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, double-click the Allows users to connect remotely using Terminal Services setting.
3.
Do one of the following:
• To enable Remote Desktop, click Enabled.
• To disable Remote Desktop, click Disabled.
If you disable Remote Desktop while users are connected to the target computers, the computers maintain their current connections, but will not accept any new incoming connections.
Important
When you enable Remote Desktop on a computer, you enable the capability for other users and groups to log on remotely to the computer. However, you must also decide which users and groups should be able to log on remotely, and then manually add them to the Remote Desktop Users group. For more information, see Enabling users to connect remotely to the server and Add users to the Remote Desktop Users group.
You should thoroughly test any changes you make to group Policy settings before applying them to users or computers. Fore more information about testing policy settings, see Resultant Set of Policy
Note
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
• Use the above procedure to configure the local Group Policy object. To change a policy for a domain or an organizational unit, you must log on to the primary domain controller as an administrator. Then, you must start Group Policy by using the Active Directory Users and Computers snap-in.
• If the Allows users to connect remotely using Terminal Services Group Policy setting is set to Not Configured, the Enable Remote Desktop on this computer setting (on the Remote tab of the System Properties dialog box) on the target computers takes precedence. Otherwise, the Allows users to connect remotely using Terminal Services Group Policy setting takes precedence.
• Be aware of the security implications of remote logons. Users who log on remotely can perform tasks as though they were sitting at the console. For this reason, you should ensure that the server is behind a firewall. For more information, see VPN servers and firewall configuration and Security information for IPSec.
• You should require all users who make remote connections to use a strong password. For more information, see Strong passwords.
• Remote Desktop is disabled by default in Windows Server 2003 operating systems.
Using System Properties
1.
Open System in Control Panel.
2.
On the Remote tab, select or clear the Enable Remote Desktop on this computer check box, and then click OK.
Important
When you enable Remote Desktop on a computer, you enable the capability for other users and groups to log on remotely to the computer. However, you must also decide which users and groups should be able to log on remotely, and then manually add them to the Remote Desktop Users group. For more information, see Enabling users to connect remotely to the server and Add users to the Remote Desktop Users group.
Note
• You must be logged on as a member of the Administrators group to enable or disable Remote Desktop.
• To open a Control Panel item, click Start, click Control Panel, and then double-click the appropriate icon.
• Any configuration set with Group Policy overrides the configuration set by using System properties, as described in this procedure.
• Be aware of the security implications of remote logons. Users who log on remotely can perform tasks as though they were sitting at the console. For this reason, you should ensure that the server is behind a firewall. For more information, see VPN servers and firewall configuration and Security information for IPSec.
• You should require all users who make remote connections to use a strong password. For more information, see Strong passwords.
• Remote Desktop is disabled by default in Windows Server 2003 operating systems.
How To Configure Terminal Services for Remote Administration Mode in Windows 2000
No additional license is required for terminal service on Window 2000.
Two simitanously users acceess are allowed.
Following is the article on how to configure the server.
http://support.microsoft.com/kb/300847
SUMMARY
This step-by-step instruction guide describes how to configure Terminal Services in Windows 2000 Server for Remote Administration mode, which allows you to manage all of your computers remotely. This document describes how to install and configure Terminal Services, how to install and run the client, and briefly describes how to make Terminal Services work over firewalls.
Back to the top
Installing Terminal Services
You can install Terminal Services in two modes: Application Server mode and Remote Administration mode. Application Server mode is used for thin-client environments in which users have lightweight PCs and run programs remotely on the server instead of locally. Application Server mode requires a license for each connected user.
Remote Administration mode allows two low-resource simultaneous connections that are ideally suited for remote administration. No additional licenses are necessary, and the limit cannot be increased. This document describes Remote Administration mode.
To Install Terminal Services
1. Insert the Windows 2000 Server CD-ROM into the CD-ROM or DVD-ROM drive.
2. If a dialog box appears automatically after you insert the CD-ROM, click Install Add-on Components. If no dialog box appears, click Start, point to Settings, and then click Control Panel. Double-click Add/Remove Programs, and then click Add/Remove Windows Components.
3. In the list of components, click to select the Terminal Services check box.
4. Click to clear the Terminal Services Licensing check box if it is selected. You do not need this service for Remote Administration mode. Click Next.
5. Click Remote Administration Mode, and then click Next.
6. The Terminal Services Wizard runs and installs Terminal Services. Close the wizard when it is finished, and then reboot your computer if you are prompted to do so.
Back to the top
Connecting to Terminal Services
To connect to Terminal Services running on a server, you must use a Terminal Services client. The client is available on the server on which you installed Terminal Services, in the following folder:
%SystemRoot%\System32\Clients\Tsclient\Net\Win32
Create a share on your server so that you can easily install the client on any computer.
To Create a Share on Your Server
1. Use Windows Explorer to locate the %SystemRoot%\System32\Clients\Tsclient\Net\Win32 folder. Note that %SystemRoot% may be the C:\Winnt folder.
2. Right-click the Win32 folder, and then click Sharing.
3. On the Sharing tab, click Share this folder.
4. Change the share name to TSClient.
5. Click Permissions.
6. Click to clear the Full control and Change check boxes. Only the Read permission should be selected.
7. Click OK, and then click OK.
Follow the next steps on the computer from which you want to perform remote administration. The Terminal Services client runs on any 32-bit version of Windows, including Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Millennium Edition (Me), Microsoft Windows NT 3.5x and 4.0, Microsoft Windows 2000 Professional, and various server versions. Connect to the share you created earlier. The share is named \\Servername\TSClient, where Servername is the name of the computer on which you installed Terminal Services. You do not have to follow the uppercase and lowercase convention that is used in this article.
To Install the Terminal Services Client
1. Connect to the \\Servername\TSClient share that you created earlier.
2. Double-click Setup.exe.
3. Click Continue in the dialog box that appears, and then type your name and organization in the next dialog box.
4. Click I agree (if you agree) when you see the license agreement.
5. Click the large button in the next dialog box. You can change the installation path first, if you want to.
6. Click Yes when you are prompted whether you want all users to have the same initial settings.
Back to the top
Using the Terminal Services Client
Before you can manage your Terminal Services servers remotely, you must create a connection to these servers. This procedure uses the Client Connection Manager tool to create icons for all of the Terminal Services servers you want to manage.
To Create a Connection to the Terminal Services Server
1. Click Start, point to Programs, point to Terminal Services Client, and then click Client Connection Manager.
2. When the Client Connection Manager Wizard starts, click Next.
3. In the Connection name box, type a descriptive name for the connection.
4. In the Server name or IP address box, type the server's name or IP address, or click Browse to search for the server. When you are done, click Next.
5. Leave all automatic logon information blank. Using automatic logon information might present a security problem if a non-administrator has access to the computer from which you run the client. Click Next.
6. Click a screen resolution that is appropriate for you. It is best to use the largest area you can select (the client does not let you select an area that is larger than your local screen can display). Do not select Full screen at this time; you can toggle between windowed and full screen modes later. Leaving the initial connection in a window helps reinforce the fact that you are working on a remote computer rather than your local workstation. Click Next.
7. Leave the Enable data compression and Cache bitmaps check boxes clear. They are useful only if you are working over a slow dial-up link. Click Next.
8. Leave the Start the following program check box clear. You want the client to display the server's desktop. Click Next. Change the icons if you want to. Click Next. Click Finish to complete the wizard.
This process creates an icon for your server. Double-clicking the icon connects you to the server. You can also right-click the icon to change the connection properties if you need to.
To Connect to the Server Using Terminal Services
1. Double-click the server icon in Client Connection Manager.
2. The Terminal Services client window appears and displays the server's logon dialog box. You might need to double-click the window's title bar to see it all.
3. Type an appropriate set of credentials to log on to the server. Typically, you will log on as some kind of administrator (local, domain, or enterprise).
4. If you use correct credentials, you see the server's desktop.
Note that this is very different from using a remote-control product. You are not manipulating the keyboard, mouse, and screen at the server. Instead, you are logged on to the computer and have created a new session, but this session is displayed remotely, over Terminal Services, rather than locally at the computer. You do, however, have full access to the computer's programs just as if you were working at its local console.
Back to the top
Disconnecting the Terminal Services client
There is an important distinction between disconnecting from a session and logging off. If you only close the Terminal Services client window, your session remains active on the server. When you connect again, Terminal Services reconnects you to that session. Any programs that you left running in the session are still available. To end the session, you need to log off by using the remote computer's Start menu. Note that this logs you off and ends the remote session. It does not log off the user at the computer's local console.
Back to the top
Useful Client Shortcut Keys
Key combination Function Similar local keys
CTRL+ALT+END Opens the Windows Security dialog box CTRL+ALT+DELETE
CTRL+ALT+BREAK Toggles the Terminal Services client display from window to full screen
ALT+INSERT Cycles through running programs on the remote computer ALT+TAB
ALT+HOME Displays the remote computer's Start menu
ALT+DELETE Displays the remote window's Control menu ALT+SPACE BAR
You can take screenshots with these shortcuts: Key combination Function Similar local keys
CTRL+ALT+NUMBER PAD MINUS Places an image of active window onto the TS clipboard ALT+PRINT SCREEN
CTRL+ALT+NUMBER PAD PLUS Places an image of the entire Terminal Services client on the Terminal Services clipboard PRINT SCREEN
Back to the top
Troubleshooting
Cannot Connect Because of a Firewall Between the Client and the Server
Terminal Services operates over TCP port 3389. If a firewall is protecting the server to which you want to connect, that firewall must permit inbound connections to the server's TCP port 3389. If you are running the client from behind a firewall, that firewall must permit outbound connections to TCP port 3389. Check with your firewall administrator for assistance.
Two simitanously users acceess are allowed.
Following is the article on how to configure the server.
http://support.microsoft.com/kb/300847
SUMMARY
This step-by-step instruction guide describes how to configure Terminal Services in Windows 2000 Server for Remote Administration mode, which allows you to manage all of your computers remotely. This document describes how to install and configure Terminal Services, how to install and run the client, and briefly describes how to make Terminal Services work over firewalls.
Back to the top
Installing Terminal Services
You can install Terminal Services in two modes: Application Server mode and Remote Administration mode. Application Server mode is used for thin-client environments in which users have lightweight PCs and run programs remotely on the server instead of locally. Application Server mode requires a license for each connected user.
Remote Administration mode allows two low-resource simultaneous connections that are ideally suited for remote administration. No additional licenses are necessary, and the limit cannot be increased. This document describes Remote Administration mode.
To Install Terminal Services
1. Insert the Windows 2000 Server CD-ROM into the CD-ROM or DVD-ROM drive.
2. If a dialog box appears automatically after you insert the CD-ROM, click Install Add-on Components. If no dialog box appears, click Start, point to Settings, and then click Control Panel. Double-click Add/Remove Programs, and then click Add/Remove Windows Components.
3. In the list of components, click to select the Terminal Services check box.
4. Click to clear the Terminal Services Licensing check box if it is selected. You do not need this service for Remote Administration mode. Click Next.
5. Click Remote Administration Mode, and then click Next.
6. The Terminal Services Wizard runs and installs Terminal Services. Close the wizard when it is finished, and then reboot your computer if you are prompted to do so.
Back to the top
Connecting to Terminal Services
To connect to Terminal Services running on a server, you must use a Terminal Services client. The client is available on the server on which you installed Terminal Services, in the following folder:
%SystemRoot%\System32\Clients\Tsclient\Net\Win32
Create a share on your server so that you can easily install the client on any computer.
To Create a Share on Your Server
1. Use Windows Explorer to locate the %SystemRoot%\System32\Clients\Tsclient\Net\Win32 folder. Note that %SystemRoot% may be the C:\Winnt folder.
2. Right-click the Win32 folder, and then click Sharing.
3. On the Sharing tab, click Share this folder.
4. Change the share name to TSClient.
5. Click Permissions.
6. Click to clear the Full control and Change check boxes. Only the Read permission should be selected.
7. Click OK, and then click OK.
Follow the next steps on the computer from which you want to perform remote administration. The Terminal Services client runs on any 32-bit version of Windows, including Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Millennium Edition (Me), Microsoft Windows NT 3.5x and 4.0, Microsoft Windows 2000 Professional, and various server versions. Connect to the share you created earlier. The share is named \\Servername\TSClient, where Servername is the name of the computer on which you installed Terminal Services. You do not have to follow the uppercase and lowercase convention that is used in this article.
To Install the Terminal Services Client
1. Connect to the \\Servername\TSClient share that you created earlier.
2. Double-click Setup.exe.
3. Click Continue in the dialog box that appears, and then type your name and organization in the next dialog box.
4. Click I agree (if you agree) when you see the license agreement.
5. Click the large button in the next dialog box. You can change the installation path first, if you want to.
6. Click Yes when you are prompted whether you want all users to have the same initial settings.
Back to the top
Using the Terminal Services Client
Before you can manage your Terminal Services servers remotely, you must create a connection to these servers. This procedure uses the Client Connection Manager tool to create icons for all of the Terminal Services servers you want to manage.
To Create a Connection to the Terminal Services Server
1. Click Start, point to Programs, point to Terminal Services Client, and then click Client Connection Manager.
2. When the Client Connection Manager Wizard starts, click Next.
3. In the Connection name box, type a descriptive name for the connection.
4. In the Server name or IP address box, type the server's name or IP address, or click Browse to search for the server. When you are done, click Next.
5. Leave all automatic logon information blank. Using automatic logon information might present a security problem if a non-administrator has access to the computer from which you run the client. Click Next.
6. Click a screen resolution that is appropriate for you. It is best to use the largest area you can select (the client does not let you select an area that is larger than your local screen can display). Do not select Full screen at this time; you can toggle between windowed and full screen modes later. Leaving the initial connection in a window helps reinforce the fact that you are working on a remote computer rather than your local workstation. Click Next.
7. Leave the Enable data compression and Cache bitmaps check boxes clear. They are useful only if you are working over a slow dial-up link. Click Next.
8. Leave the Start the following program check box clear. You want the client to display the server's desktop. Click Next. Change the icons if you want to. Click Next. Click Finish to complete the wizard.
This process creates an icon for your server. Double-clicking the icon connects you to the server. You can also right-click the icon to change the connection properties if you need to.
To Connect to the Server Using Terminal Services
1. Double-click the server icon in Client Connection Manager.
2. The Terminal Services client window appears and displays the server's logon dialog box. You might need to double-click the window's title bar to see it all.
3. Type an appropriate set of credentials to log on to the server. Typically, you will log on as some kind of administrator (local, domain, or enterprise).
4. If you use correct credentials, you see the server's desktop.
Note that this is very different from using a remote-control product. You are not manipulating the keyboard, mouse, and screen at the server. Instead, you are logged on to the computer and have created a new session, but this session is displayed remotely, over Terminal Services, rather than locally at the computer. You do, however, have full access to the computer's programs just as if you were working at its local console.
Back to the top
Disconnecting the Terminal Services client
There is an important distinction between disconnecting from a session and logging off. If you only close the Terminal Services client window, your session remains active on the server. When you connect again, Terminal Services reconnects you to that session. Any programs that you left running in the session are still available. To end the session, you need to log off by using the remote computer's Start menu. Note that this logs you off and ends the remote session. It does not log off the user at the computer's local console.
Back to the top
Useful Client Shortcut Keys
Key combination Function Similar local keys
CTRL+ALT+END Opens the Windows Security dialog box CTRL+ALT+DELETE
CTRL+ALT+BREAK Toggles the Terminal Services client display from window to full screen
ALT+INSERT Cycles through running programs on the remote computer ALT+TAB
ALT+HOME Displays the remote computer's Start menu
ALT+DELETE Displays the remote window's Control menu ALT+SPACE BAR
You can take screenshots with these shortcuts: Key combination Function Similar local keys
CTRL+ALT+NUMBER PAD MINUS Places an image of active window onto the TS clipboard ALT+PRINT SCREEN
CTRL+ALT+NUMBER PAD PLUS Places an image of the entire Terminal Services client on the Terminal Services clipboard PRINT SCREEN
Back to the top
Troubleshooting
Cannot Connect Because of a Firewall Between the Client and the Server
Terminal Services operates over TCP port 3389. If a firewall is protecting the server to which you want to connect, that firewall must permit inbound connections to the server's TCP port 3389. If you are running the client from behind a firewall, that firewall must permit outbound connections to TCP port 3389. Check with your firewall administrator for assistance.
Subscribe to:
Posts (Atom)