Windows Server 2008
Control the Issuance of RDS CALs in Windows Server 2008 R2 PDF 
Bookmark and Share

This post is for customers or administrators who want to control which Remote Desktop Session Host (RD Session Host) servers are issued Remote Desktop Services client access licenses (RDS CALs) and which version of RDS CAL is issued to the RD Session Host servers. By default, a Remote Desktop license server issues an RDS CAL (if an appropriate RDS CAL is available) to any RD Session Host server that requests one on behalf of a client that is trying to connect to the RD Session Host server. This post also discusses how to control the auto-discovery of a license server running Windows Server 2008 R2 from terminal servers running Windows Server 2008 or Windows Server 2003.

Control which RD Session Host servers are issued RDS CALs

For security reasons, you might want to specify the RD Session Host servers to which a license server offers RDS CALs. You can apply the License server security group Group Policy setting to a Remote Desktop license server to control which RD Session Host servers are issued RDS CALs by the license server.

  • If you apply this policy setting to a Remote Desktop license server, it responds only to requests for RDS CALs from RD Session Host servers whose computer accounts are members of the Terminal Server Computers group.
    Note: The Terminal Server Computers group is created as a local group on the license server the first time the Remote Desktop Licensing service is started on the license server. By default, the Terminal Server Computers group is empty. If you disable or do not configure the License server security group policy setting, the Terminal Server Computers group is not deleted or changed and the license server issues an RDS CAL (if an appropriate RDS CAL is available) to any RD Session Host server that requests one.
  • You should enable the License server security group policy setting when the license server is a member of a domain so that only you can add computer accounts for RD Session Host servers to the Terminal Server Computers group. The policy setting has no effect if you enable it on a license server that is a member of a workgroup; the license server continues to issue RDS CALs to any RD Session Host server that requests RDS CALs from the license server.

Location of the License server security group policy setting: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\RD Licensing

If the License server security group policy setting is enabled and applied to a license server, it is noted in Review Configuration in the Remote Desktop Licensing Manager tool (Click Start -> Administrative Tools -> Remote Desktop Services -> Remote Desktop Licensing Manager. In the left pane, right-click the server name under the All servers node and select the Review Configuration option).

To verify whether an RD Session Host server is allowed to request RDS CALs from the Remote Desktop license server, you can use the IsSecureAccessAllowed method of Win32_TSLicenseServer class. For more details about this method, click here.

Control which version of RDS CAL is issued to RD Session Host servers

By default, a license server attempts to provide the most appropriate RDS CAL for a connection. For example, a license server running Windows Server 2008 R2 tries to issue a Windows Server 2008 R2 RDS CAL for clients connecting to an RD Session Host server running Windows Server 2008 R2, and a Windows Server 2003 TS CAL for clients connecting to a terminal server running Windows Server 2003.

If the most appropriate RDS CAL is not available, a license server running Windows Server 2008 R2 issues a Windows Server 2008 R2 RDS CAL, if available, to a client connecting to a terminal server running Windows Server 2003 or Windows Server 2000.

You can use the Prevent license upgrade Group Policy setting on the license server so that it issues only a temporary RDS CAL to the client if an appropriate RDS CAL is not available (if the licensing mode of the RD Session Host server is set to Per Device). If the client has already been issued a temporary RDS CAL and the temporary RDS CAL has expired, the client will not be able to connect to the RD Session Host server, unless the RD Licensing grace period for the RD Session Host server has expired.

Note: As the Per User licensing mode is not enforced, the license server will issue the appropriate version of CAL even if the Group Policy setting is not set. You need to have the appropriate number and version of CALs to be compliant with the Microsoft Software License Terms.

Location of the Prevent license upgrade policy setting: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\RD Licensing

To verify whether the Prevent license upgrade Group Policy setting is enabled or not, you can use the IsLSPreventUpgradeGPEnabled method of Win32_TSLicenseServer class. For more details about this method, click here.

Control the auto-discovery of the Remote Desktop license server

In Windows Server 2003 and Windows Server 2008, the terminal servers (now Remote Desktop Session Host servers) were configured to auto-discover the license server by default. If you want to over-ride the license server discovery process, this KB article might help you. In case you want your terminal server to discover the license servers automatically but don’t want your license server running Windows Server 2008 R2 to be discoverable by terminal servers running Windows Server 2008 or Windows Server 2003, here are some tips:

  • If you have installed your license server in a domain scope and don’t want it to be discoverable by down-level terminal servers, install it on a domain-joined machine but not on the domain controller. If you install your license server on the domain controller, all down-level terminal servers will be able to discover that license server.
  • If you have installed your license server in a forest/enterprise scope and don’t want it to be discoverable by down-level terminal servers, un-publish the license server. To un-publish the license server, you can use the UnpublishLS method of the Win32_TSLicenseServer class. For more details about this method, click here.
  • If you don’t want your license server to be discoverable in some other site/domain than the current one, un-publish it from that particular site/domain.
Tags:
Read more
Add comment (0)
Hits: 572
 
Deploying Windows 2008 R2 RD Gateway R2 server with NAP PDF 
Bookmark and Share

1. Background

Network Access Protection (NAP) is a policy-enforcement platform built into Windows. It is designed to inspect, assess, ensure compliance to policy, and remediate, where necessary, endpoints (such as laptops or other devices) attempting to access networked resources (such as applications, data, and information).

NAP is designed to protect client computers, networks, edge devices and hosts from malware by verifying the client’s health and making it compliant to corporate network policies. This set of technologies allows an IT administrator to keep the endpoints healthy at all times and enable access control based on health policies.

In Windows Server 2008 R2, RD Gateway (formerly referenced as TS Gateway) has significant improvements in its integration with NAP. Using this release, administrator can configure RD Gateway to remediate the client or provide information to users on compliance to enable them to make the right decisions. In all the RDG system can now evaluate the client health for logging, enforce peripheral redirect or access using NAP, and remediate clients on connection attempts.

2. RD Gateway and NAP remediation

RD Gateway enables access to corpnet applications and desktops from the Internet or intranet. Remote users have the flexibility to connect from corporate-owned, domain-joined, or private workgroup machines.

While RDG enables application access from unmanaged machines this also exposes corporate resources to added risk. For instance, a private workgroup machine infected with a virus can potentially infect the RD Server and other corporate resources as well. Using NAP RDG can solve the unmanaged machine access problem while improving security. This is done through RD client integration with NAP to collect any state information available to NAP and RD gateway integration with NAP which enables health enforcement. Together the systems support a variety of client health checks and enforcement modes, such as:

  1. Deny connection and auto-remediate domain joined client desktops if the anti-virus and automatic updates are turned off.
  2. Deny connection to private workgroup machine if anti-virus and automatic updates are turned off.
  3. Allow connection with client device redirection turned OFF and in parallel auto-remediate the domain joined client machine with critical security updates. Turning off client devices like hard-drives, disks, PnP, clip-boards will reduce the risk to the terminal server.

3. Systems Capabilities Matrix

Client connecting to RDG server

WS 2008 RDG

WS 2008 R2 RDG

RDC 6.0/6.1

Health check enforcement

Health check enforcement

RDC 7.0

Health check enforcement

Health check and auto remediation

NOTE: The RDG-NAP solution will not work from Windows Server RDC clients

4. Recommendations

  • Turn on auto-remediation for unhealthy domain-joined corporate machines. This is recommended to automatically remediate client machines before allowing access to corporate resources.
  • Turn off client device redirection (refer section 5.a.4) for non-compliant and non-NAP capable clients. This ensures that users continue to remain productive, and, because device redirection is turned off, it provides some level of isolation for the client machine from the corporate network.
  • Turn off auto-remediation for unhealthy private workgroup machines. This is recommended if you don’t want private machines to be automatically remediated without user consent. Users can attempt a manual remediation based on server health response.

5. RDC7.0 Client-side configuration

  • RD Gateway NAP auto-remediation requires RDC 7.0 clients connecting to a Windows Server 2008 R2 server.
  • Common settings required –
    • The RDG certificate needs to be placed in COMPUTER TRUSTED store.
    • You must add the RD Gateway server to the trusted gateway list. Please refer to this URL for more details: http://technet.microsoft.com/en-us/library/cc732172(WS.10).aspx#BKMK_ConfigureNAPClient_TSGateway

6. Configuring WS2008 R2 RD Gateway Server for specialized NAP scenarios

This section provides administrators with the steps to configure RD Gateway for various NAP scenarios.

a. Configure RD gateway to turn off device redirection from unhealthy clients

  1. Configure network access protection (NAP). For information on creating NAP, refer to the section "Steps to configure the NAP policies"
  2. Click Start > Administrative tools > Remote Desktop Services > Remote Desktop Gateway Manager to open the RD Gateway manager snap-in.
  3. Click Policies and then click Connection Authorization Policies. Choose the NAP policy corresponding to non-compliance, and then select the Device Redirection tab.
    image
  4. On the Device Redirection tab, disable the client devices.
    image

b. Configure RD gateway to deny access to unhealthy clients

  1. Configure Network access policies (NAP). For information on creating NAP, refer the section "Steps to configure the NAP policies"
  2. On the Network policy server snap-in, open Network Policies. Choose the NAP policy corresponding to RD Gateway non-compliance, select Settings
  3. On the NAP RD Gateway Noncompliant properties page, select NAP Enforcement and enable Allow Limited Access.
    image

c. Configure WS2008 R2 RD gateway to auto-remediate unhealthy clients

  1. Configure network access policies (NAP). For information on creating NAP, refer to the section "Steps to configure the NAP policies".
  2. On the Network policy server snap-in, open Network Policies. Choose the NAP policy corresponding to RD Gateway non-compliance, and then select Settings.
    image
  3. On the NAP RD Gateway Noncompliant properties page, select NAP Enforcement. Select “Enable auto remediation of client computers.”
    *Note that the RD gateway auto-remediation scenario only works when the remediation servers are directly accessible from the internet.
    image

7. RDC 7.0 Client experiences

The following screenshots provide the user experience for an unhealthy client machine. In this case, the RDG is configured to deny access and auto-remediate the client.

  1. Users is denied connection and informed with a balloon of the status.
    image
  2. The user clicks the NAP tray and is notified of the status. Due to certain limitations, the status does not change until the user closes the MSTSC process completely.
    image
  3. The user closes the MSTSC process and is immediately informed with a balloon of the green status.
    image
  4. The user attempts to connect again and succeeds.

8. Configuring WS2008 R2 NAP policies

a. Steps to configure the NAP policies

  1. Administrator configures RD Gateway CAP with NAP SoH using Network Policy Server manager snap-in. Click Start, click Administrative tools, and then click Network Policy Server.
  2. Click Configure NAP.
    image
  3. On the Select Network Connection Method for Use with NAP page, choose Remote Desktop Gateway (RD Gateway) as the network connection method and specify a name in the Policy name section. Click Next.
  4. On the Specify NAP Enforcement Servers Running RD Gateway page, add RD Gateway servers running remotely and using the central NPS. In cases where the NPS and RD Gateway roles are co-located on the same server, you can skip this screen. Click Next.
  5. On the Configure Client Device Redirection and Authentication Methods page, configure the device redirection and authentication method policies. Click Next.
  6. On the Configure the Idle Timeout and Session Timeout Actions page, configure the Enable idle Timeout and Enable session timeout policy. Click Next.
  7. On the Configure User Groups and Machine Groups page, configure Machine groups and User Groups that are allowed access. Click Next.
  8. On the Define NAP Health Policy page, select Windows System Health Validator. On the Network access restrictions for NAP-ineligible client computers, choose the network action policy.
    *To configure the Windows System Health Validator, refer to the section "Steps to configure System heath Validator".
  9. Click Finish

b. Steps to configure WS2008 R2 System Health Validator

  1. User configures a System Health Validator on the Network Policy Server manager snap-in. Click Start > Administrative tools > Network Policy Server.
  2. Click Network Access Protection à System Health Validators à Windows Security Health Validator. à Settings.
    image
  3. Click Default Configuration, Choose the policy settings for Windows System Health Validators.

9. References

RD Gateway NAP step-by-step WS08 (includes client configuration for NAP):

http://technet.microsoft.com/en-us/library/cc732172(WS.10).aspx


Read Full Article
Tags:
Read more
Add comment (0)
Hits: 537
 
Web Single Sign-On for RemoteApp and Desktop Connections with Windows 2008 R2 PDF 
Bookmark and Share

In Windows Server 2008 R2, the Web Single Sign-On (Web SSO) feature provides users with the ability to enter
their credentials only once during logon to Remote Desktop Web Access (RD Web Access). After logon, users can
launch RemoteApp programs that are part of the same connection in RemoteApp and Desktop Connections without
any further credential prompts, even if the RemoteApp programs are configured to use RD Gateway.

This post describes how to configure RD Session Host and RD Connection Broker servers to take advantage of the
Web SSO feature when launching RemoteApp programs from RD Web Access.

Why is Web SSO necessary?

In Windows Server 2008 TS Web Access, a major pain point for users was receiving multiple credential prompts, first when
logging on to TS Web Access and then when launching a RemoteApp program from a terminal server.

In Windows Server 2008 R2, using the new RD Web Access Forms Based Authentication (FBA), users will now have to enter
credentials only once in the login page of RD Web Access and will not be prompted again for entering credentials on launching
subsequent apps from the RemoteApp Programs page of RD Web Access.

How it works

RD Web Access can access RemoteApp programs in two modes (details about these modes can be found in this post):

  • RD Session Host mode for small to medium deployments
  • RD Connection Broker mode for large deployments
What is supported

Web SSO is supported for launching RemoteApp programs from RD Web Access or the Start menu in any of the above modes. It will not work, however, for connections to personal desktops or pooled virtual machines (VMs).

Requirements
  • To take advantage of the new Web SSO feature, the client must be running Remote Desktop Connection (RDC) 7.0.
  • In order for Web SSO to work:
    1. The connection in RemoteApp and Desktop Connections must have an ID. By default, it is set to the Fully Qualified Domain Name (FQDN) of the RD Connection Broker server in case of RD Connection Broker mode. In RD Session mode, it is set to the FQDN of the RD Web Access server.
    2. RemoteApp programs must be digitally signed using a Server Authentication certificate [Secure Sockets Layer (SSL) certificate]. The certificate Enhanced Key Usage section must contain ‘Server Authentication (1.3.6.1.5.5.7.3.1)’. More details about the types of certificates used to digitally sign RemoteApp programs can be found here.
    3. Client operating systems must trust the certificate with which the RemoteApp programs are signed.

The steps for configuring Web SSO and setting up a digital signature for RemoteApp programs for RD Session Host and RD Connection Broker modes are described below.

Configuring Web SSO when using RD Session Host mode

There are 2 steps required to configure Web SSO when using RD Session Host.

  • Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Session Host server
  • Step 2: Digitally sign the RemoteApp programs on the RD Session Host server

Membership in the local Administrators group (or equivalent) on the RD Session Host server that you plan to configure is the minimum requirement to complete each of the following steps.

Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Session Host server

  1. On the RD Session Host server, click Start, point to Administrative Tools, and then click Computer Management.
  2. In the left pane, expand Local Users and Groups, and then click Groups.
  3. In the right pane, double-click TS Web Access Computers.
  4. In the TS Web Access Computers Properties dialog box, click Add.
  5. In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types.
  6. In the Object Types dialog box, select the Computers check box, and then click OK.
  7. In the Enter the object names to select box, specify the computer accounts of the RD Web Access server and the RD Connection Broker server, and then click OK.
  8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 2: Digitally sign the RemoteApp programs on the RD Session Host server

  1. On the RD Session Host server, open RemoteApp Manager. To open RemoteApp Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
  2. In the Actions pane of RemoteApp Manager, click Digital Signature Settings. (Or, in the Overview pane, next to Digital Signature Settings, click Change.)
  3. Select the Sign with a digital certificate check box.
  4. In the Digital certificate details box, click Change.
  5. In the Select Certificate dialog box, select the certificate that you want to use, and then click OK.

    Note: The Select Certificate dialog box is populated by certificates that are located in the local computer's certificates store or in your personal certificate store. The certificate that you want to use must be located in one of these stores.

Configuring Web SSO when using RD Connection Broker mode

There are 5 steps required to configure Web SSO when using RD Connection Broker.

  • Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Connection Broker server
  • Step 2: Add RD Session Host servers as RemoteApp Sources on RD Connection Broker server
  • Step 3: Add the RD Connection Broker server to TS Web Access Computers group on each RD Session Host server
  • Step 4: Digitally sign the RemoteApp programs on each RD Session Host server
  • Step 5: Specify certificate on RD Connection Broker server
    Note: The certificate for digitally signing RemoteApp programs on each RD Session Host server and RD Connection Broker server should be the same.

Membership in the local Administrators group, or equivalent, on the specific server that you plan to configure is the minimum required to complete each of the following steps.

Step 1: Add the RD Web Access server to the TS Web Access Computers group on the RD Connection Broker server

  1. On the RD Connection Broker server, click Start, point to Administrative Tools, and then click Computer Management.
  2. In the left pane, expand Local Users and Groups, and then click Groups.
  3. In the right pane, double-click TS Web Access Computers.
  4. In the TS Web Access Computers Properties dialog box, click Add.
  5. In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types.
  6. In the Object Types dialog box, select the Computers check box, and then click OK.
  7. In the Enter the object names to select box, specify the computer accounts of the RD Web Access server and the RD Connection Broker server, and then click OK.
  8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 2: Add RD Session Host servers as RemoteApp Sources on RD Connection Broker server

  1. On the RD Connection Broker server, open Remote Desktop Connection Manager. To open Remote Desktop Connection Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Connection Manager.
  2. In the left pane, click RemoteApp Sources, and then on the Action menu, click Add RemoteApp Source.
  3. In the Add RemoteApp Source dialog box, in the RemoteApp source name box, enter the name of the RD Session Host server or the DNS name of the RD Session Host server farm that is hosting the RemoteApp programs, and then click Add.
    Note: Do not enter the name of each RD Session Host server in the RD Session Host server farm. If you do, users will see multiple instances of the RemoteApp program icons.
  4. The RemoteApp source name will appear in the center pane. To add additional RemoteApp sources, repeat the previous steps.

Step 3: Add the RD Connection Broker server to TS Web Access Computers group on each RD Session Host server

  1. On the RD Session Host server, click Start, point to Administrative Tools, and then click Computer Management.
  2. In the left pane, expand Local Users and Groups, and then click Groups.
  3. In the right pane, double-click TS Web Access Computers.
  4. In the TS Web Access Computers Properties dialog box, click Add.
  5. In the Select Users, Computers, or Groups dialog box, click Object Types.
  6. In the Object Types dialog box, select the Computers check box, and then click OK.
  7. In the Enter the object names to select box, specify the computer account of the RD Connection Broker server, and then click OK.
  8. Click OK to close the TS Web Access Computers Properties dialog box.

Step 4: Digitally sign RemoteApp programs on each RD Session Host server

Use the following steps to sign RemoteApp programs by using RemoteApp Manager. The procedure assumes that you are working from a central administrator workstation, the certificate is stored on the central administrator workstation, and the central administrator workstation has the RemoteApp Manager tool installed.

  1. On the central administrator workstation, open RemoteApp Manager. To open RemoteApp Manager, click Start, click Administrative Tools, click Remote Desktop Services, and then click RemoteApp Manager.
  2. On the Action menu, click Connect to Computer.
  3. Select Another Computer, enter the fully qualified domain name (FQDN) of the RD Session Host server, and then click OK.
  4. On the Action menu, click Digital Signature Settings.
  5. Select the Sign with a digital certificate check box.
  6. Click Change, select the certificate to be used for signing, and then click Apply.
  7. Click OK to close the RemoteApp Deployment Settings dialog box.

Repeat the steps in the procedure for each RD Session Host that is providing RemoteApp programs through RemoteApp and Desktop Connection.

Step 5: Specify certificate on RD Connection Broker server

  1. On the RD Connection Broker server, open Remote Desktop Connection Manager. To open Remote Desktop Connection Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Connection Manager.
  2. Select the root ‘Remote Desktop Connection Manager: <RD Connection Broker Machine Name> ’
  3. In the middle pane, in the Status area, click on Specify beside the Digital certificate (shown below).

    image
  4. Follow ‘Step 2: Digitally sign RemoteApp programs on RD Session Host server’ in the ‘Configuring Web SSO when using RD Session Host mode’ section above.

Configuring the client computer for Web SSO

If the RemoteApp programs are signed using a certificate from a public CA that participates in the Microsoft Root Certificate Program Members program (http://go.microsoft.com/fwlink/?LinkID=59547), then Web SSO should just work.

If the certificate is not issued by a trusted public CA, the certificate must be imported into the Trusted Root Certification Authorities certification store on the client computer to be trusted by the client operating system. Members of the local Administrators group, or equivalent, on the client computer can import the certificate or it can be done by using Group Policy.

The ‘Trusted Certificate Authority Root’ certificate (shown below) must be imported in the Trusted Root Certification Authorities certification store on the client computer and on the RD Session Host and RD Connection Broker machines. ‘Certificate for Signing Remote App Programs’ certificate must be imported in the Personal store on the RD Session Host, and RD Connection Broker machines.

image

Web SSO in Windows Integrated Authentication

If RD Web Access is configured to use Windows Authentication, which is the Windows Server 2008 mode, instead of the default Forms Based Authentication (FBA), users will be prompted for credentials twice: once for the Windows Integrated Authentication for RD Web Access and again on the launch of the first RemoteApp in the RemoteApp and Desktop Connection. Thereafter on subsequent RemoteApp launch, SSO will work as it works in the FBA mode.

Web SSO with RD Gateway

Web SSO also works when RemoteApp programs are set to use RD Gateway regardless of whether RD Web Access accesses RemoteApp programs in RD Session Host mode or RD Connection Broker mode.

The configuration of Web SSO for RD Gateway assumes that:

  • an RD Gateway is deployed
  • a ‘Connection Authorization Policy’ is set to use password for the users connecting
  • and the RD Gateway server is used by RemoteApp programs

More details on how to configure a ‘Connection Authorization Policy’ on RD Gateway can be found here.

The step below is needed regardless of the mode RD Web Access is configured. In case of RD Connection Broker mode, the step needs to be performed on each RD Session Host server which is added as a RemoteApp Source on RD Connection Broker Server.

Membership in the local Administrators group (or equivalent) on the RD Session Host server that you plan to configure is the minimum requirement to complete each of the following steps.

  1. On the RD Session Host server, open RemoteApp Manager. To open RemoteApp Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
  2. In the Actions pane of RemoteApp Manager, click RD Gateway Settings. (Or, in the Overview pane, next to RD Gateway Settings, click Change.)
  3. Select the Use these RD Gateway server settings.
  4. In the Server name box, click the FQDN of the RD Gateway server.
  5. In the Logon box, select the Ask for password (NTLM).
  6. Select the Use the same user credentials for RD Gateway and RD Session Host server check box.
  7. Click OK to close the RemoteApp Deployment Settings dialog box.
Tags:
Read more
Add comment (0)
Hits: 1320
 
Infrastructure Planning and Design Guides for Windows Server 2008 R2 Now Available PDF 
Bookmark and Share

In support of the upcoming Windows Server 2008 R2 launch, Microsoft announced at the Worldwide Partner Conference 2009 this week the public release of Infrastructure Planning and Design Guides Series for Windows Server 2008 R2 - free best practice and guidance available to help Microsoft customers and partners accelerate their planning process of Windows Server 2008 R2 deployment projects.

The newly-released Infrastructure Planning and Design Guides for Windows Server 2008 R2 outline the critical infrastructure design elements that are crucial to a successful implementation of Windows Server 2008 R2. You will be guided through the multi-step process of designing components, layout, and connectivity in a logical, sequential order. Following the steps in these guides will result in a design that is sized, configured, and appropriately placed to deliver the stated business benefits, while also considering the performance, capacity, and fault tolerance of the system.

The following guides in the Infrastructure Planning and Design series have been updated to reflect new features and capabilities available in Windows Server 2008 R2:

  • Active Directory Domain Services
  • Internet Information Services 7.5 (IIS)
  • File Services
  • Print Services

Download the IPD Guides now and select a guide or guides from the “IPD Guides for Windows Server” section under the IPD One-click Downloads, listed on the bottom right of the page.

Infrastructure Planning and Design streamlines the planning process by:

  • Defining the technical decision flow through the planning process.
  • Listing the decisions to be made and the commonly available options and considerations.
  • Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
  • Framing decisions in terms of additional questions to the business to ensure a comprehensive alignment with the appropriate business landscape.

Get IPD Guides now!

Join the Beta
Additional Infrastructure Planning and Design guides are available as beta releases on the Connect Web site. They are open beta downloads. See below for instructions on how to access the beta guides. To join the Infrastructure Planning and Design Beta, follow these steps:

  • Visit the Infrastructure Planning and Design Beta at http://connect.microsoft.com.
  • Sign in using a valid Windows Live ID to continue to the Invitations page.
  • Scroll down to Infrastructure Planning and Design.

If you have not previously registered with Microsoft Connect, you might be required to register before continuing with the invitation process. If the link in step 1 does not work for you, copy the link and paste it into the Web browser address bar.

Tags:
Read more
Add comment (0)
Hits: 211