jump to navigation

What Is IPSec?: Security Policy; Security Services April 25, 2012

Posted by John Ruby in Microsoft KBs, Troubleshooting & Knowledge Bases.
add a comment

 

Internet Protocol security (IPSec) is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. Because IPSec is integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite, and because IPSec is applied transparently to applications, there is no need to configure separate security for each application that uses TCP/IP.

IPSec helps provide defense-in-depth against:

  • Network-based attacks from untrusted computers, attacks that can result in the denial-of-service of applications, services, or the network
  • Data corruption
  • Data theft
  • User-credential theft
  • Administrative control of servers, other computers, and the network.

What Is IPSec?: Security Policy; Security Services

Advertisements

Installing a server role on a server running a Server Core installation of Windows Server 2008 R2: Overview April 25, 2012

Posted by John Ruby in Microsoft KBs, Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

Installing a server role on a server running a Server Core installation of Windows Server 2008 R2: Overview

After the Server Core installation is complete and the server is configured, you can install one or more server roles. The Server Core installation of Windows Server 2008 R2 supports the following server roles:

  • Active Directory Certificate Services
  • Active Directory Domain Services
  • Active Directory Lightweight Directory Services (AD LDS)
  • DHCP Server
  • DNS Server
  • File Services (including File Server Resource Manager)
  • Hyper-V
  • Streaming Media Services
  • Print and Document Services
  • Web Server (including a subset of ASP.NET)

Installing a server role on a server running a Server Core installation of Windows Server 2008 R2: Overview

Recommended private “Heartbeat” configuration on a cluster server March 20, 2010

Posted by John Ruby in Microsoft KBs.
add a comment

Recommended private "Heartbeat" configuration on a cluster server
Recommended private "Heartbeat" configuration on a cluster server

Communication between Server Cluster nodes is critical for smooth cluster operations. Therefore, you must configure the networks that you use for cluster communication are configured optimally and follow all hardware compatibility list requirements. For networking configuration, two or more independent networks must connect the nodes of a cluster to avoid a single point of failure. The use of two local area networks (LANs) is typical. (Microsoft Product Support Services does not support the configuration of a cluster with nodes connected by only one network.)

At least two of the cluster networks must be configured to support heartbeat communication between the cluster nodes to avoid a single point of failure. To do so, configure the roles of these networks as either "Internal Cluster Communications Only" or "All Communications" for the Cluster service. Typically, one of these networks is a private interconnect dedicated to internal cluster communication.

Additionally, each cluster network must fail independently of all other cluster networks. This means that two cluster networks must not have a component in common that can cause both to fail simultaneously. For example, the use of a multiport network adapter to attach a node to two cluster networks would not satisfy this requirement in most cases because the ports are not independent.

To eliminate possible communication issues, remove all unnecessary network traffic from the network adapter that is set to Internal Cluster communications only (this adapter is also known as the heartbeat or private network adapter). Clustering communicates by using Remote Procedure Call (RPC) calls on IP sockets with User Datagram Protocol (UDP) packets. The process described in this article:

  • Removes NetBIOS from the interconnect.
  • Sets the proper Cluster communication priority order.
  • Sets the proper adapter binding order.
  • Defines the proper network adapter speed and mode.
  • Configures TCP/IP correctly.
  • Disable the Media Sense feature (in Windows 2000 only).

Note The information in this article does not apply to Windows Server 2008 or Windows Server 2008 R2 failover clusters. Implementing these recommendations on these versions of failover clustering can cause adverse behavior. Windows Server 2008 and Windows Server 2008 R2 failover clusters do not have to have a private heartbeat network and the networking settings in this article are not needed and may cause unwanted behavior.

MORE INFORMATION

Recommended configuration for the private adapter in Windows 2000 and Windows 20…

Recommended configuration for the private adapter in Windows 2000 and Windows 2003

  1. Click Start, point to Settings, click Control Panel, and then double-click Network and Dial-up Connections.
  2. On the Advanced menu, click Advanced Settings.
  3. In the Connections box, make sure that your bindings are in the following order, and then click OK:
    • External public network
    • Internal private network (Heartbeat)
    • [Remote Access Connections]
  4. Right-click the network connection for your heartbeat adapter, and then click Properties.

    Note You may want to rename this connection for simplicity (for example, rename it to "Private").

  5. Use one of the following procedures:
    • If the server is using a quorum type other than Majority Node Set (MNS), click to select Internet Protocol (TCP/IP), and then click to clear all other options.
    • If the server is using a MNS quorum, click to select Internet Protocol (TCP/IP) and at least one other file-sharing network protocol, and then click to clear all other options.

      Note If the server is using a MNS quorum, you must have at least one network that has file-sharing capabilities for the MNS quorum to function. We strongly recommend that you have multiple networks on the cluster that have file sharing enabled to avoid a single point of failure for the quorum resource.

  6. If you have a network adapter that can transmit at multiple speeds, and the adapter can specify a speed and duplex mode, manually specify a speed and duplex mode.

    With network adapters that can manually specify a speed and duplex mode, make sure that you hard set them to the same on all nodes and according to the manufacturers’ specifications. For network adapters that do not support manual settings, follow the card manufacturer’s specifications.

    The information that is traveling across the heartbeat network is small, but latency is critical for communication. If you have the same the speed and duplex settings, this helps to make sure that you have reliable communication.

    If you are not sure of the supported speed of your card and connecting devices, or your manufacturer’s recommended settings, Microsoft recommends that you set all the devices on that path of 10 MB/Sec and Half Duplex. This configuration will provide sufficient bandwidth and reliable communication. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    174812  (http://support.microsoft.com/kb/174812/ ) The effects of using Autodetect setting on cluster network interface card

    Note: Microsoft does not recommend the use of any type of fault-tolerant adapter or "Teaming" for the heartbeat. If you require redundancy for your heartbeat connection, use multiple network adapters set to Internal Communication Only and define their network priority in the Cluster configuration. Issues seen with early multi-ported network adapters, verify that your firmware and driver are at the most current revision if you use this technology.

    Contact your network adapter manufacturer for information about compatibility on a Server Cluster. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    254101  (http://support.microsoft.com/kb/254101/ ) Network adapter teaming and server clustering
  7. Click Internet Protocol (TCP/IP), and then click Properties.
  8. On the General tab, verify that you have selected a static IP address that is not on the same subnet or network as another one of the public network adapters. An example of good IP addresses to use for the private adapters is 10.10.10.10 on node 1 and 10.10.10.11 on node 2 with a subnet mask of 255.0.0.0. If your public network uses the 10.x.x.x network and 255.0.0.0 subnet mask please use an alternate private network IP and subnet. For more information about valid IP addressing for a private network, click the following article number to view the article in the Microsoft Knowledge Base:
    142863  (http://support.microsoft.com/kb/142863/ ) Valid IP addressing for a private network
  9. Make sure that there is no value set in the Default Gateway box.
  10. Verify that there are no values defined in the Use the following DNS server addresses box.

    Note If the cluster nodes are also DNS servers, "127.0.0.1" is displayed in the Use the following DNS server addresses box (the box will not be blank); this is acceptable.

  11. Click Advanced.
  12. On the DNS tab, verify that there are no values defined. Make sure that the Register this connection’s addresses in DNS and Use this connection’s DNS suffix in DNS registration check boxes are cleared.
  13. When you close the dialog box, you may receive the following prompt. If you receive this prompt, click Yes:
    This connection has an empty primary WINS address. Do you want to continue?
  14. If you are using a crossover cable for your private heartbeat interconnect, disable the TCP/IP stack destruction feature of Media Sense.

    Note Do not perform this step on a Windows Server 2003 Cluster.

    To have us disable the TCP/IP stack destruction feature of Media Sense for you, go to the "Fix it for me" section. To disable the TCP/IP stack destruction feature of Media Sense yourself, go to the "Let me fix it myself" section.

    Fix it for me

    To disable the TCP/IP stack destruction feature of Media Sense automatically, click the Fix this problem link. Click Run in the File Download dialog box, and follow the steps in this wizard.

    Fix this problem
    Microsoft Fix it 50316

    Note this wizard may be in English only; however, the automatic fix also works for other language versions of Windows.

    Note If you are not on the computer that has the problem, you can save the automatic fix to a flash drive or to a CD, and then you can run it on the computer that has the problem.

    Now continue to the next step.

    Let me fix it myself

    To disable the TCP/IP stack destruction feature of Media Sense add the following registry value to each node:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

    Value Name: DisableDHCPMediaSense
    Data Type: REG_DWORD
    Data: 1

    For more information about this, click the following article number to view the article in the Microsoft Knowledge Base:

    254651  (http://support.microsoft.com/kb/254651/ ) Cluster network role changes automatically
  15. Complete the previous steps on all other nodes in the cluster.
  16. Start Cluster Administrator.
  17. Click the cluster name at the root of Administrator. On the File menu, click Properties.
  18. On the Network Priority tab, verify that the private network is listed at the top. If it is not, use the Move Up button to increase its priority.
  19. Click the private network, and then click Properties.
  20. Click to select the Enable this network for cluster use check box.
  21. Click Internal cluster communications only (private Network).

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

281662  (http://support.microsoft.com/kb/281662/ ) Windows 2000 and Windows Server 2003 cluster nodes as domain controllers

Recommended configuration for the private adapter in Windows NT 4.0

  1. Click Start, point to Settings, click Control Panel, and then double-click Network.
  2. On the Protocols tab, click TCP/IP Protocol, and then click Properties.
  3. In the Adapter box, click the private network adapter.
  4. On the IP Address tab, verify that you have selected a static IP address that is not on the same subnet or network as another one of the public network adapters. An example of good IP addresses to use for the private adapters is 10.10.10.10 on node 1 and 10.10.10.11 on node 2 with a subnet mask of 255.0.0.0.
  5. Make sure that there is no value set in the Default Gateway box.
  6. On the WINS Address tab, click the heartbeat adapter in the Adapter box.
  7. Verify that there are no values defined for the WINS server entries.
  8. When you close the dialog box, you may receive the following prompt. If you receive this prompt, click Yes:
    At least one of the adapter cards has an empty primary WINS address. Do you want to continue?
  9. On the Routing tab, verify that the Enable IP Forwarding check box is cleared.
  10. Click OK.
  11. If you have a network adapter that can transmit at multiple speeds and can specify a speed and duplex mode, manually specify a speed and duplex mode.

    With network adapters that can manually specify a speed and duplex mode, make sure that you hard set them to the same on all nodes and according to the manufacturer’s specifications. For network adapters that do not support manual settings, follow the card manufacturer’s specifications.

    The information that is traveling across the heartbeat network is small, but latency is critical for communication. If you have the same speed and duplex settings, you can help make sure that you have reliable communication.

    If you do not know the supported speed of your card and connecting devices, Microsoft recommends you set all devices on that path to 10 MB/Sec and Half Duplex. This configuration provides sufficient bandwidth and reliable communication. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    174812  (http://support.microsoft.com/kb/174812/ ) The effects of using Autodetect setting on cluster network interface card

    Note Microsoft does not recommend that you use any type of fault-tolerant adapter or "Teaming" for the heartbeat. If you require redundancy for your heartbeat connection, use multiple network adapters set to Internal Communication Only and define their network priority in the Cluster configuration. Issues seen with early multi-ported network adapters, verify that your firmware and driver are at the most current revision if you use this technology.

    Contact your network adapter manufacturer for information about compatibility on a Server Cluster. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    254101  (http://support.microsoft.com/kb/254101/ ) Network adapter teaming and server clustering
  12. On the Bindings tab, click All Adapters in the Show Bindings For box.
  13. Click the plus sign (+) next to the adapter used for the private interconnect.
  14. Click WINS Client (TCP/IP), and then click Disable.Note No protocols other than TCP/IP should be enabled on the heartbeat adapter. Verify that all others are disabled (including such items as Network Monitor).
  15. In the Show Bindings For box, click All Protocols.
  16. Click the plus sign (+) next to TCP/IP Protocol.
  17. Make sure that the public network adapter is the first binding (at the top of the binding list). To do this, click the private network adapter and use the Move Down button. If you have multiple public network adapters, make sure the heartbeat adapter is listed last. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    193890  (http://support.microsoft.com/kb/193890/ ) Recommend WINS configuration for Microsoft cluster server
  18. Click OK to finish modifying the network properties and accept the changes.
  19. Reboot the node for the changes to take effect.
  20. Complete the previous steps on all other nodes in the cluster.
  21. Start Cluster Administrator.
  22. Click the cluster name at the root of Administrator. On the File menu, click Properties.
  23. On the Network Priority tab, verify that the private network is listed at the top. If it is not, use the Move Up button to increase its priority.
  24. Click the private network, and then click Properties.
  25. Click to select the Enable this network for cluster use check box.
  26. Click Internal cluster communications only (private Network).

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

281662  (http://support.microsoft.com/kb/281662/ ) Windows 2000 cluster nodes as domain controllers


APPLIES TO
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows NT Server 4.0 Enterprise Edition

How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup) January 8, 2010

Posted by John Ruby in Microsoft KBs.
add a comment

How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup)
How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup)

Use this procedure to manage nodes to an existing SQL Server failover cluster instance.

Important:
To update or remove a SQL Server failover cluster, you must be a local administrator with permission to log in as a service on all nodes of the failover cluster. For local installations, you must run Setup as an administrator. If you install SQL Server from a remote share, you must use a domain account that has read and execute permissions on the remote share.

Setup does not install .NET Framework 3.5 SP1 on a clustered operating system. You must install .NET Framework 3.5 SP1 before you run Setup.

You may need to apply cumulative updates to the original media before you install SQL Server 2008, if you are affected by a known issue in the setup program. For more information about known issues and detailed instructions, see .

Note that Setup operations for SQL Server failover clustering have changed in this release. To install or upgrade a SQL Server failover cluster, you must run the Setup program on each node of the failover cluster.

To add a node to an existing SQL Server failover cluster, you must run SQL Server Setup on the node that is to be added to the SQL Server failover cluster instance. Do not run Setup on the active node.

To remove a node from an existing SQL Server failover cluster, you must run SQL Server Setup on the node that is to be removed from the SQL Server failover cluster instance.

To view procedural steps to add or remove nodes, select one of the following operations:

Important:
The operating system drive letter for SQL Server install locations must match on all the nodes added to the SQL Server failover cluster.

 Add Node

 To add a node to an existing SQL Server 2008 failover cluster

  1. Insert the SQL Server installation media, and from the root folder, double-click setup.exe. To install from a network share, navigate to the root folder on the share, and then double-click Setup.exe. You may be asked to install the prerequisites if they are not previously installed.

  2. Windows Installer 4.5 is required, and may be installed by the Installation Wizard. If you are prompted to restart your computer, restart, and then start SQL Server 2008 Setup.exe again.

  3. When prerequisites are installed, the Installation Wizard will launch the SQL Server Installation Center. To add a node to an existing failover cluster instance, click Installation in the left-hand pane. Then, select Add node to a SQL Server failover cluster.

  4. The System Configuration Checker will run a discovery operation on your computer. To continue, click OK. Setup log files have been created for your installation. For more information about log files, see How to: View and Read SQL Server Setup Log Files.

  5. On the Product key page, specify the PID key for a production version of the product. Note that the product key you enter for this installation must be for the same SQL Server 2008 edition as that which is installed on the active node.

  6. On the License Terms page, read the license agreement, and then select the check box to accept the licensing terms and conditions. To continue, click Next. To end Setup, click Cancel.

  7. The Installation Wizard will install SQL Server prerequisites if they are not already on the computer. They include the following:

    • SQL Server Setup Support Files

    To install prerequisites, click Install.

  8. The System Configuration Checker will verify the system state of your computer before Setup continues. After the check is complete, click Next to continue.

  9. On the Cluster Node Configuration page, use the drop-down box to specify the name of the SQL Server 2008 failover cluster instance that will be modified during this Setup operation.

  10. On the Server Configuration — Service Accounts page, specify login accounts for SQL Server services. The actual services that are configured on this page depend on the features you selected to install. For failover cluster installations, account name and startup type information will be pre-populated on this page based on settings provided for the active node. You must provide passwords for each account. For more information, see SQL Server Configuration – Service Accounts and Setting Up Windows Service Accounts.

    Security Note   Do not use a blank password. Use a strong password.

    When you are finished specifying login information for SQL Server services, click Next.

  11. On the Error and Usage Reporting page, specify the information you would like to send to Microsoft that will help to improve SQL Server. By default, options for error reporting and feature usage are enabled. For more information, see Error and Usage Report Settings.

  12. The System Configuration Checker will run one more set of rules to validate your computer configuration with the SQL Server features you have specified.

  13. The Ready to Add Node page displays a tree view of installation options that were specified during Setup.

  14. Add Node Progress page provides status so you can monitor add node progress as Setup proceeds.

  15. After installation, the Complete page provides a link to the summary log file for the installation and other important notes. To complete the SQL Server installation process, click Close.

  16. If you are instructed to restart the computer, do so now. It is important to read the message from the Installation Wizard when you are done with Setup. For information about Setup log files, see How to: View and Read SQL Server Setup Log Files.

 Remove Node

 To remove a node from an existing SQL Server 2008 failover cluster

  1. Insert the SQL Server installation media. From the root folder, double-click setup.exe. To install from a network share, navigate to the root folder on the share, and then double-click setup.exe. . If the Microsoft SQL Server 2008 Setup dialog box appears, click OK to install the prerequisites, then click Cancel to quit the SQL Server 2008 installation.

  2. Windows Installer 4.5 is required, and may be installed by the Installation Wizard. If you are prompted to restart your computer, restart and then start SQL Server 2008 setup.exe again.

  3. When prerequisites are installed, the Installation Wizard will launch the SQL Server Installation Center. To remove a node from an existing failover cluster instance, click Maintenance in the left-hand pane, and then select Remove node from a SQL Server failover cluster.

  4. The System Configuration Checker will run a discovery operation on your computer. To continue, click OK. Setup log files have been created for your installation. For more information about log files, see How to: View and Read SQL Server Setup Log Files.

  5. The Installation Wizard will install SQL Server prerequisites if they are not already on the computer. They include the following:

    • SQL Server Setup Support Files

    To install prerequisites, click Install.

  6. The System Configuration Checker will verify the system state of your computer before Setup continues. After the check is complete, click Next to continue.

  7. On the Cluster Node Configuration page, use the drop-down box to specify the name of the SQL Server 2008 failover cluster instance that will be modified during this Setup operation. The node that will be removed will be listed in the "Name of this node" field.

  8. The Ready to Remove page displays a tree view of options that will be removed during Setup. To continue, click Remove.

  9. During the remove operation, the Remove Node Progress page provides status.

  10. The Complete page provides a link to the summary log file for the remove node operation and other important notes. To complete the SQL Server remove node operation, click Close. For information about Setup log files, see How to: View and Read SQL Server Setup Log Files.

Changes to remote administration in Windows Server 2008 January 8, 2010

Posted by John Ruby in Microsoft KBs.
add a comment

Changes to remote administration in Windows Server 2008

Changes to remote administration in Windows Server 2008 and Windows Server 2008 R2

In Windows Server 2003, you can start the RDC client (Mstsc.exe) by using the /console switch to remotely connect to the physical console session on the server (also known as session 0). In Windows Server 2008 or Windows Server 2008 R2, the /console switch has been deprecated. For more information, see the “Why the /console switch is no longer needed” section. In Windows Server 2008 and Windows Server 2008 R2, session 0 is a noninteractive session that is reserved for services.

You can use the new /admin switch to remotely connect to a Windows Server 2008-based server for administrative purposes. The /admin switch is introduced in RDC 6.1. RDC 6.1 is included in the following operating systems:

  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Vista Service Pack 1 (SP1)
  • Windows XP Service Pack 3 (SP3)
Note RDC 6.1 (6.0.6001) supports Remote Desktop Protocol (RDP) 6.1.

RDC 6.1 does not support the /console switch. However, for backward compatibility, you can use the /admin switch to connect to the physical console session on a Windows Server 2003-based server. For example, to connect from a Windows Vista SP1-based client to the physical console session of a Windows Server 2003-based server, run the mstsc.exe /admin command.

If you try to use the /console switch together with the RDC 6.1 client, the behavior is as follows.

Collapse this tableExpand this table
Scenario Behavior
You type mstsc.exe /console at the command prompt, and then you connect to a remote server that does not have Terminal Server installed. The /console switch is silently ignored. You will be connected to a session to remotely administer the server.
For more information about the Windows Server 2008 or Windows Server 2008 R2 behavior, see the "When you connect to a server that does not have Terminal Server installed" section.
You type mstsc.exe /console at the command prompt, and then you connect to a remote server that has Terminal Server installed. The /console switch is silently ignored. You will be connected to a standard Remote Desktop session that requires a Terminal Services client access license (TS CAL).
In the RDC client UI, you specify Computer_name /console in the Computer box, and then you click Connect.

Note Computer_name represents the name of the remote computer to which you want to connect.

You receive an “An unknown parameter was specified in computer name field" error message.
In the .rdp file, you specify /console in the full address property, and then you try to start the Remote Desktop connection. You receive an "An unknown parameter was specified in computer name field" error message.
In the .rdp file, you specify the connect to console property, and then you start the Remote Desktop connection. The property is silently ignored. You will be connected to a session that requires a TS CAL.
You programmatically call the put_ConnectToServerConsole function or the get_ConnectToServerConsole function of the IMsRdpClientAdvancedSettings interface. The function fails, and it returns an S_FALSE value.

Why the /console switch is no longer needed

In Windows Server 2003, you use the Mstsc.exe /console command to start a Remote Desktop session for the following reasons:

  • To connect to session 0
    Some applications are installed and run only in session 0. This is because the applications have to communicate with services that run in session 0 or because the applications have to display user interface (UI) elements that are displayed in session 0.
  • To connect back to an existing session on the physical console
    Because the physical console session in Windows Server 2003 is always session 0, the only way that you can reconnect to this session is by using the /console switch.

In Windows Server 2008 and Windows Server 2008 R2, the /console switch functionality is no longer needed for the following reasons:

  • Improved application compatibility guarantees that legacy applications that have to communicate with services in session 0 will be installed and run in sessions other than session 0. Additionally, if the service that is associated with an application tries to display UI elements in session 0, a built-in capability in Windows Server 2008, Windows Server 2008 R2 and in Windows Vista enables you to view and to interact with the session 0 UI from your session. Windows Server 2008/Windows Server 2008 R2 session 0 is a noninteractive session that is reserved for services. Therefore, there is no need for you to explicitly connect to this session.

    Note For more information about session 0 isolation in Windows Vista, view the "Impact of Session 0 Isolation on Services and Drivers in Windows Vista" topic on the following Microsoft Web site:

  • Because the physical console session is never session 0, you can always reconnect to your existing session on the physical console. The Restrict Terminal Services users to a single remote session Group Policy setting determines whether you can connect to your existing physical console session. This setting is available in the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections node of the Local Group Policy Editor. You can also configure this setting in Terminal Services Configuration. The Restrict each user to a single session setting appears in Edit settings in the General section.

How the /admin switch behaves

You can run the RDC 6.1 client (Mstsc.exe) together with the /admin switch to remotely administer a Windows Server 2008-based server that has or does not have Terminal Server installed. However, if you are trying to remotely administer a Windows Server 2008-based server that does not have the Terminal Server role service installed, you do not have to use the /admin switch. In this case, the same connection behavior occurs with or without the /admin switch. At any point in time, there can be two active remote administration sessions. To start a remote administration session, you must be a member of the Administrators group on the server to which you are connecting.

When you connect to a server that does not have Terminal Server installed

If a member of the Administrators group starts a Remote Desktop session to a Windows Server 2008-based server that does not have the Terminal Server role service installed, the following conditions are true for the remote administration session:

  • Time zone redirection is disabled.
  • Terminal Services Session Broker (TS Session Broker) redirection is disabled.
  • Plug and Play device redirection is disabled.
  • The remote session theme is changed to Windows Classic.
  • Terminal Services Easy Print is disabled.

When you connect to a server that has Terminal Server installed

If a member of the Administrators group starts a Remote Desktop session to a Windows Server 2008-based server that has the Terminal Server role service installed, they must use the /admin switch to connect to a session to remotely administer the server. The following conditions are true for the session:

  • You do not have to have a TS CAL to remotely administer a terminal server.
  • Time zone redirection is disabled.
  • Terminal Services Session Broker redirection is disabled.
  • Plug and Play device redirection is disabled.
  • The remote session theme is changed to Windows Classic.
  • Terminal Services Easy Print is disabled.

Changes to APIs

If you are using RDC 6.1, you can no longer use the ConnectToServerConsole property of the IMsRdpClientAdvancedSettings interface to specify whether the Remote Desktop ActiveX control should try to connect to the server for administrative purposes. Instead, you must use the ConnectToAdministerServer property of the IMsRdpClientAdvancedSettings6 interface to connect to one of the following sessions:

  • The physical console session on a Windows Server 2003-based computer
  • The session that is used for administrative purposes on a Windows Server 2008-based computer

For more information about the ConnectToServerConsole property, visit the following Web site:

For more information about the ConnectToAdministerServer property, visit the following Web site:

Talking about Disk performance may be slower than expected when you use multiple disks in Windows Server 2003 August 13, 2009

Posted by John Ruby in Microsoft KBs.
add a comment

 

Quote

Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in
Disk performance may be slower than expected when you use multiple disks in Microsoft Windows Server 2003, in Microsoft Windows XP, and in Microsoft Windows 2000. For example, performance may slow when you use a hardware-based redundant array of independent disks (RAID) or a software-based RAID.