Interoperability

Why Is Interoperability Important?

It should come as no surprise that many medium- and large-sized organizations usually have mixed or what is sometimes referred to as heterogeneous computing environments. Research data shows that there are 2 million UNIX servers, 300,000 AS/400 systems, and more than 50,000 IBM-compatible mainframes. The Microsoft® Windows® operating system is also broadly deployed in these organizations, but with so many disparate systems, the issue of interoperability becomes increasingly important. As an example, consider that many organizations are deploying distributed n-tier client/server applications, many of which require access to data or transactions on existing systems. In general, Microsoft has seen at least three main drivers for interoperability:

1.

Reduces operational cost and complexity – Customers will continue to have mixed environments for the foreseeable future. The ability for these systems to work together reduces the cost of building and supporting a heterogeneous infrastructure. Having said that, it's worth noting that homogeneity may, in fact, offer substantial benefits in reducing the operational cost and complexity of an organization's infrastructure. However, it is unlikely that many organizations have the ability to create a totally homogeneous environment.
2.

Enables “best-of-breed” deployments – Customers may have business requirements that can only be delivered with specific applications or platforms. For example the Windows NT® platform provides a rich platform to either build solutions or buy commercial “off-the-shelf” application packages. This best-of-breed environment meets the requirements for rapidly deploying solutions. However, it's clear that Windows NT needs to work with the other environments in use in the organization; otherwise, the potential benefits of the new solution would be reduced. So interoperability is a key requirement that can help ensure customers meet their demanding business needs.
3.

Leverages existing investments – Customers have a large and diverse range of systems installed in their environments. The move to new platforms needs to be gradual and evolutionary. Interoperability between new environments such as applications based on Windows DNA and existing systems is critical to the success of the Windows platform in the enterprise. Another key trend is the requirement to “Web enable” existing applications, allowing access to the key systems on host environments, such as the IBM mainframe, from the intranet or Internet. This Web enabling effectively extends the functionality of existing applications and protects the investments that organizations have made.

What is Microsoft's Interoperability Strategy?

Microsoft is committed to ensuring that the Windows platform works with other key platforms and systems in the heterogeneous computing environment of our customers.

In order to achieve this goal, Microsoft will broadly adopt two tactics: it will build bridges and/or gateways to the key platforms in use by our customers; and it will support key standards that can provide interoperability to systems that also support the standard.

In summary, rather than advocate replacing equipment in a piecemeal fashion, the Microsoft goal is to help customers evolve their information technology infrastructures in ways that capitalize on new technologies and products. This commitment to interoperability improves information sharing, reduces computing costs, and capitalizes on past investments.
Microsoft Interoperability Framework

In order to communicate and fill out its interoperability strategy, Microsoft has defined a framework for the technologies that enable Microsoft products to work in a multivendor environment. This framework is divided into four layers: Network, Data, Applications, and Management—or NDAM for short. Standards that play a key role in enabling interoperability between systems span all four layers of the framework.

ndam

For a more detailed look at the Microsoft interoperability strategy and the NDAM framework, you can read the Microsoft Interoperability Strategy white paper. If you're interested in interoperability with a specific platform or at a specific layer of the NDAM framework, the navigation menus on the right will help you find the resources you need.

Network Interoperability

Network interoperability provides the core foundation for Interoperability between systems. We can think of network interoperability as the ability for multivendor systems to communicate with each other using common protocols. Network interoperability includes the following:

Protocols – Protocols are the base technology for all interoperability. Microsoft has invested heavily in a wide range of protocols such as TCP/IP, IPX/SPX, and SNA, which provide support to access a wide range of platforms other than Windows, including UNIX, Apple Macintosh, Novell Netware, and IBM hosts. However, other base interoperability is delivered with support for protocols such as the Dynamic Host Configuration Protocol (DHCP), Domain Name Service (DNS), and internetworking protocols such as Router Information Protocol.

TerminalAccess – Support for terminal protocols is clearly a very important first step in providing access to existing systems. In the past, terminal support has often been the major requirement for access and interoperability for many customers. Microsoft has developed support through Microsoft SNA Server for 3270 and 5250 as well as the TN3270 and TN5250 protocols. However, it is clear many customers require more sophisticated interoperability than simple terminal access, and these requirements are more likely categorized as data or application interoperability.

Print Services – The ability for applications or users to take advantage of print resources on multiple systems can be a very important requirement. Microsoft continues to support this requirement through support for a variety of protocols including new emerging protocols such as the Internet Printing Protocol.

Data Interoperability

Data Interoperability delivers the ability for users and applications to access and query information stored in both structured and unstructured storage engines. As an example, users very often need to get access to data from multiple sources as well as the ability to search across these sources.

File System – Network file servers such as Novell Netware or UNIX NFS hosts contain large amounts of information that often needs to be shared among users, and often these users are on different systems. Microsoft supports access to these multiple file systems in numerous ways including the native protocols such as IPX/SPX, NCP, and NFS.

Database – Clearly a great deal of corporate data resides in databases such as Oracle and IBM DB/2. Having database access to these systems is critical for both users and applications. Additionally, the ability to perform heterogeneous queries against multiple databases provides extremely powerful capabilities. Another requirement is the ability to provide replication between multiple database systems including bidirectional support. This is important in applications such as data warehousing, for example, where data is extracted from transactional systems on a scheduled basis and is replicated to a data warehouse so that users can perform complex analysis on this data. Through Data Transformation Services, OLEDB, and other Microsoft technologies, Microsoft is enabling comprehensive database interoperability capabilities.

E-mail Access and Storage – While a great deal of corporate data resides in either databases or flat files, an increasing amount of data resides in the semi-structure storage engine of messaging systems. Additionally, not only is access to e-mail data important, but the ability to send and receive e-mail as well as schedule information is essential for most companies. Microsoft supports key messaging standards such as SMTP, IMAP4, and POP3 to enable interoperability as well as build support for connectors to foreign mail systems such as OfficeVision and cc:Mail.

Applications Interoperability

Application interoperability refers to the key infrastructure required to ensure that new applications built in the n-tier client server model can interoperate with existing applications, business logic, and data.

Presentation Services – The demand for organizations to build applications that reach out to customers and partners is increasing as organizations look to the Internet as a new channel for working with customers and partners. This creates the challenge of having to build applications that run on clients that you have little control over. The use of the browser and support for HTML provides the broadest reach, but for a richer experience, the use of DHTML offers a combination of good reach and rich interactive functionality.

Transactions – The ability for applications to participate in transactions between multiple systems is a key requirement that follows on the simple access to data across systems. This ability to update the data across multiple databases and systems can be achieved in a number of ways, from proprietary mechanisms such as IBM CICS and APPC protocols through to standards-based protocols such as XA and TIP.

Components – As organizations rearchitect and develop applications in the n-tier client server model, the ability to create reusable components that can be invoked by many applications becomes increasingly important. This componentization occurs across all levels of the application, and the ability to have the same programming model brings many benefits. The COM programming model provides the ability to wrap existing business logic on systems not running Windows into a COM object that can be invoked by a Windows-based application. Additionally, third parties provide interoperability between different component models such as COM and CORBA.

Management Interoperability

Management interoperability focuses on reducing the burden of administration of multiple systems, in particular the challenges of user accounts management. However, it should be noted that management interoperability is substantially more than this, and while the current focus is not addressing this broader set of requirements, future developments by Microsoft and other vendors are likely to address this requirement.

Security – The administrative overhead of managing users and passwords on multiple systems is a very substantial burden. Additionally, the user experience of having to input multiple user names and passwords as well as remember all the passwords is clearly an undesirable situation. Microsoft has been developing technology to help with single sign-on and password synchronization to platforms including UNIX, Novell Netware, and IBM S/390 and IBM AS/400. In addition, Microsoft is supporting standards such as Kerberos that provide the foundation for more comprehensive single sign-on solutions to platforms that support the Kerberos v5 protocol.

Directory – Directory services provide a consistent way to name, locate, access, manage, and secure network resources. On the network, directory and security infrastructure is typically very tightly integrated within the operating system to ensure maximum security as well as ease of deployment and administration. Having to manage multiple, incompatible directories can significantly increase the total cost of ownership. Therefore, directory interoperability is a priority for many customers. Microsoft's Active Directory provides support for standards such as LDAP, which provides a level of interoperability as well as support for specific directory service synchronization with NDS.

Systems Management – The ability to manage events, alerts, performance characteristics, and so on across platforms is an important requirement especially as n-tier applications may pass through multiple layers on different systems, and the ability to manage the performance or events is critical. Again Microsoft is working on technologies that will provide the basis for management across multiple environments. For example, Microsoft has supported SNMP for many years and with the Windows Management Architecture, a range of additional protocols and functionality is being developed in Windows to provide the basis for a richer management infrastructure for the heterogeneous environment. Additionally, third-party vendors have a key role to play in facilitating an enterprise management architecture that includes the Windows Management Architecture.

Standards

Standards play a key role in enabling interoperability between systems. There are many examples of how standards are in use today as the basis of interoperability with industry standards defined by groups of companies cooperating in consortia (such as SMTP or HTML) and technologies defined by individual companies that are so widely adopted as to become "de facto standards" (such as IPX/SPX or SNA).

There is not a simple one-to-one relationship, however, between industry standards and interoperability. The relationship is far more complex. Some industry standards are initially narrow or incomplete, and a variety of extensions and common practices grow up around them, driven by market forces. For example, the early leading Web browser vendors created a number of non-standard extensions and practices (for example, ignoring the absence of many HTML end-tags when the end could be inferred from context) that are now required to render a large amount of HTML content. Other standards solve a certain key issue in a general problem space and leave other aspects of the problem space undefined. For example, the LDAP standard for directory services focuses on client enumeration and simple query of a directory server but does not specify optimized server-to-server communication or replication, does not define how secure directory access should occur, and does not define a number of the important data structures or "schemas" needed in a fully functional directory service. (These limitations may be addressed in future versions of LDAP.)

Finally, even in its functional area, the best and most precisely specified industry standard is never able to capture on paper the full range of expected functionality and semantics of a complex system. Implementation and cross-testing of implementations is always necessary to work out all the details necessary for true interoperability. That is why the IETF (Internet Engineering Task Force), for example, wisely refuses to create final standards unless multiple implementations of a given specification have actually been built and tested against each other. That is also why Microsoft and other companies seeking real interoperability aggressively test their implementations against each other from an early beta phase either in informal "bake-offs" or through industry bodies that provide interoperability and testing services

Clearly, industry standards have a key role to play in establishing and enhancing interoperability. But "standards" need to be conceived of more broadly than simply as paper specifications produced by independent bodies. A true standard includes both a specification and a set of industry practices that emerge from that specification. Moreover, specifications that are never broadly adopted in the marketplace can hardly be called "standards" in any meaningful sense; at best they can be thought of as potential standards that might eventually be actualized through industry adoption.

Microsoft is committed to interoperability and therefore committed to standards. Microsoft will continue to work hard within the standards process to help develop and adopt key standards that solve interoperability.

lancer out

Administering Remote Assistance

Administering Remote Assistance

Abstract
This article explains how to manage Remote Assistance for users in a corporate environment. It is intended for administrators familiar with the Windows 2000 Active Directory™ service and Group Policy.

Acknowledgements
Mike Seamans, Technical Writer, Microsoft Corporation
Alvin Loh, Program Manager, Microsoft Corporation
John Kaiser, Technical Editor, Microsoft Corporation

On This Page
Introduction
Using Remote Assistance Through A Firewall
Using Remote Assistance with NAT Devices
Using Group Policy for Remote Assistance
Blocking Remote Assistance on an Individual Computer
Offering Help via Remote Assistance
Summary
Related Links

Introduction

Remote Assistance enables a trusted person (a friend, support person, or IT administrator) to remotely and actively assist someone with a computer problem. The helper (also called an expert) can view the screen of the user requesting assistance and offer advice. With the permission of the user, the helper can take control of the user's computer and perform tasks remotely.
Remote Assistance requires that both computers are running Windows XP.
Types of Remote Assistance connections
Remote Assistance can be used in the following situations:
• Within a local area network (LAN).
• Over the Internet.
• Between an individual on the Internet and an individual behind a firewall on a LAN. Connections through a firewall require that TCP port 3389 be open.

Securing Remote Assistance

If a user permits it, and it is allowed by Group Policy, a helper can control the user's computer and perform any task that the user can perform, including accessing the network. To address security concerns within your organization, the following settings are available:

· At the firewall. You can determine whether a person within your organization can request help outside of the organization by prohibiting or permitting inbound and outbound traffic through port 3389 at the firewall. For more information, see the section in this article, Using Remote Assistance Through a Firewall.

· Group Policy. You can set Group Policy to permit or prohibit users from requesting help using Remote Assistance. You can also determine whether users can allow someone to remotely control their computer, or just view it.

In addition, you can set Group Policy to permit or prohibit a helper from offering Remote Assistance without a specific request from the user.

For more information, see the section in this article, Using Group Policy for Remote Assistance.

· Individual computer. The administrator of an individual computer can turn off Remote Assistance requests on that computer; this prevents anyone using the computer from sending a Remote Assistance invitation. For more information, see the section in this article, Blocking Remote Assistance on an Individual Computer.

Offering Remote Assistance

Remote Assistance normally begins with a user requesting help, either through e-mail or Windows Messenger. However, a helper can also offer help without first receiving a request from a novice. For more information, see the section in this article, Offering Help via Remote Assistance.

Using Remote Assistance Through A Firewall

Remote Assistance uses the Remote Desktop Protocol (RDP) to establish a connection between a user requesting help and a helper providing it. The RDP uses TCP port 3389 for this connection. To allow users within an organization to request help outside your organization using Remote Assistance, port 3389 must be open at the firewall. To prohibit users from requesting help outside the organization, this port should be closed at the firewall.

Refer to the instructions for administering the firewall for information about opening or closing port 3389.

Notes:

· If you close port 3389, you will block all Remote Desktop and Terminal Services through this port. If you want to allow these services but want to limit Remote Assistance requests, use Group Policy.

· Microsoft's Internet Connection Firewall, which is designed to be used only with stand-alone computers or computers in a workgroup, does not block Remote Assistance traffic.

Using Remote Assistance with NAT Devices

What is NAT?

Network Address Translation is an Internet Engineering Task Force (IETF) standard used to allow multiple PCs or devices on a private network (using private address ranges such as 10.0.x.x, 192.168.x.x, 172.x.x.x) to share a single, globally routable IPv4 address. A main reason NAT is often deployed is because IPv4—the current generation of the Internet—addresses are getting scarce.

NAT is used in gateway devices that form the boundary between the public Internet and the private LAN. As IP packets from the private LAN traverse the gateway, NAT translates a private IP address and port number to a public IP address and port number, tracking those translations to keep individual sessions intact. Internet Connection Sharing in the Windows XP and Windows Me operating systems, along with many Internet gateway devices use NAT, particularly to connect to broadband networks such via DSL or cable modems. The use of NAT is increasing dramatically as more homes and small businesses network their PCs and share a connection to the Internet.

Remote Assistance and NAT

Remote Assistance supports UPnP to Traverse NAT devices, allowing connections through NAT devices unless both the Novice and Expert are behind a non-UPnP NAT device. At this time, Windows XP Internet Connection Sharing supports UPnP.

Here's how Remote Assistance works with UPnP:

1. Remote Assistance will detect the Public Internet IP address and TCP Port number on the UPnP NAT device and insert the address into the Remote Assistance ticket.

2. The Public Internet Address and TCP Port number will be used to connect through the NAT device by the Expert or Novice workstation to establish a Remote Assistance session.

3. The Remote Assistance connection request will then be forwarded to the client by the NAT device.

Note: Remote Assistance will not connect when the Novice is behind a non-UPnP NAT device when e-mail is used to send the invitation file. When sending an invitation using Windows Messenger, a non-UPnP NAT device will work if one client is behind a NAT device. If both expert and novice computers are behind Non-UPnP NAT devices then the Remote Assistance connection will fail.

There are several NAT Networking companies that are looking into supporting UPnP by the end of this year. Table 1 below shows Remote Assistance connections that work through NAT devices. Note: Windows 2000 ICS does not support UPnP.

Table 1. Remote Assistance connections and NAT devices

	Windows XP ICS	Non-UPnP NAT Device	UPnP NAT Device
Connecting via Windows Messenger
Novice	Yes	Yes	Yes
Expert	Yes	Yes	Yes
Both Novice and Expert	Yes	No	Yes
Connecting via e-mail
Novice	Yes	No	Yes
Expert	Yes	Yes	Yes
Both Novice and Expert	Yes	No	Yes

Using Group Policy for Remote Assistance

In an Active Directory Windows 2000 Server environment, you can use Group Policy to manage Remote Assistance—setting levels of permissions or blocking its use entirely.

Use the policy Solicited Remote Assistance located in the Group Policy Snap-in (Computer Configuration\Administrative Templates\System\Remote Assistance), as shown in Figure 1 below.

Figure 1: . Managing Remote Assistance via Group Policy

Solicited remote assistance is where the user of a computer explicitly requests help from another party, known as a helper.

Preventing Remote Assistance

The policy setting Solicited Remote Assistance is not configured by default, which means individual users will be able to configure solicited remote assistance via the control panel. The default settings via the control panel are: solicited remote assistance is enabled, buddy support is enabled, remote control is enabled, and the maximum ticket time is 30 days.

Therefore, in order to prohibit users from accessing Remote Assistance, you need to disable the policy Solicited Remote Assistance. This will prohibit Remote Assistance for any computer or user subject to the Group Policy Object (GPO) affected by the setting. For example, you may wish to prevent certain groups of users from accessing Remote Assistance. A user who is a member of a given Organizational Unit (OU) subject to this policy setting will not be able to use Remote Assistance.

Managing Remote Assistance

Enabling Solicited Remote Assistance allows you to set permissions that differ from the default settings that are enabled when this policy is not configured. As in the case explained earlier, you may wish to manage how certain groups of users can use Remote Assistance. A user who is a member of a given Organizational Unit (OU) subject to this policy setting will be able to use Remote Assistance, according to the permissions you set.

Note: Sending a help request does not explicitly give the expert permission to connect to the computer and/or control it. When the expert tries to connect, the user will still be given a chance to accept or deny the connection (giving the helper view-only privileges to the user's desktop) and will afterward have to explicitly click a button to give the expert the ability to remotely control the desktop if remote control is enabled.

If the setting is enabled, you can set the following configuration options:

· Allow buddy support. Checking this checkbox means that a user can request help from other individual users (such as friends or coworkers, via e-mail or instant messaging.) as well as via an official channel set up by an software or hardware vendor, corporate helpdesk, and so on. Unchecking this box means that a user can only request help through an official channel.

· Permit remote control of this computer. This selection allows you to choose whether an expert will be able to remotely control the computer or whether the expert is only allowed to remotely view the user's desktop.

· Maximum ticket time. These two settings control the maximum time a user can have a help request remain valid. When the ticket (help request) expires, the user must send another request before an expert can connect to the computer.

Blocking Remote Assistance on an Individual Computer

Users can block Remote Assistance on their own computers by adjusting settings in the control panel.

To block Remote Assistance requests on an individual computer

1. Open Control Panel, click Performance and Maintenance, and then click System.

2. On the Remote tab, under Remote Assistance, clear the Allow Remote Assistance invitations to be sent from this computer check box, as shown in Figure 2 below.

Figure 2:

]. Blocking Remote Assistance

To prevent someone from using Remote Assistance to take control of this computer

1. Open System in Control Panel.

2. On the Remote tab, under Remote Assistance, click Advanced.

3. Clear the Allow this computer to be controlled remotely check box, as shown in Figure 3 below.

Figure 3: . Preventing access to your computer via Remote Assistance

Offering Help via Remote Assistance

Sometimes the best way to help someone fix a problem is to demonstrate a solution. If you are an expert or Helpdesk support professional, you can initiate a Remote Assistance request without an invitation. For example, you may be communicating with a friend about a computer issue and elect to resolve it via Remote Assistance.

After you are connected, you will be able to view the user's computer screen and chat together about what you both see. With that person's permission, you can use your mouse and keyboard to control his or her computer.

Notes:

· Firewalls can prevent a Remote Assistance connection. Try using Windows Messenger instead of e-mail to start the connection. If that doesn't work, ask the network administrator to add port 3389 for you.

· If Offer Remote Assistance is enabled in the Group Policy editor on a user's computer, a helper can offer Remote Assistance to that user without an explicit invitation. The helper must have been added as a helper on that person's computer in the Group Policy editor, or be a member of the Administrator's group on that computer.

· You can improve performance during a Remote Assistance session by reducing the color quality on the user's computer. Use the Color Quality setting on the Settings tab in Display (in Control Panel) to reduce the number of colors his or her screen displays.

To offer Remote Assistance without an invitation

1. Click Start, and then click Help and Support.

2. Under Pick a task, click Tools.

3. Under Tools in the left pane, click Offer Remote Assistance.

4. Type the name or the IP address of the computer you want to connect to, and then click Connect, as shown in Figure 4 below.

Figure 4: . Offering Remote Assistance

To offer Remote Assistance to a user who has not sent an explicit invitation, the Offer Remote Assistance setting in Group Policy must be enabled on the user's computer, as shown in Figure 5 below.

Figure 5: . Enabling Group Policy to Offer Remote Assistance

In addition, you must be either a member of the Administrators group on that computer or listed as a helper under Offer Remote Assistance on that computer, as shown in Figure 6 below.

Figure 6: . Adjusting the Offering Remote Assistance policy setting

To enable Offer Remote Assistance on a computer

1. Click Start, click Run, type gpedit.msc, and then click OK.

2. In the left pane of the Group Policy editor, under Computer Configuration, double-click Administrative Templates, double-click System, and then double-click Remote Assistance.

3. In the right pane, double-click Offer Remote Assistance, and then click Enabled. Once enabled, you can determine whether the helper can view the computer or control it.

Although a helper can offer Remote Assistance without being asked, the user must give permission before the helper can see the user's computer. In addition, the user must give explicit permission before the helper can control the user's computer (if that feature is enabled).

Summary

Managing Remote Assistance may require adjusting settings for port 3389, configuring Group Policy Objects, and other administration tasks.

Administrators can manage Remote Assistance through the following:

· Firewall. Administrators can determine whether a person within your organization can request help outside of the organization by prohibiting or permitting inbound and outbound traffic through port 3389 at the firewall.

· Group Policy. You can set Group Policy to permit or prohibit users from requesting help using Remote Assistance. You can also determine whether users can allow someone to remotely control their computer, or just view it. In addition, you can set Group Policy to permit or prohibit a helper from offering Remote Assistance without a specific request from the user.

· Individual computer. The administrator of an individual computer can turn off Remote Assistance requests on that computer; this prevents anyone using the computer from sending a Remote Assistance invitation.

Related Links

See the following resources for further information:

· Managing Windows XP in a Windows 2000 Server Environment at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mngwinxp.mspx.

· Step-by-Step Guide to Remote Assistance at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rmassist.mspx.

· Using Remote Assistance at http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/remoteassist/intro.mspx

For the latest information about Windows XP, see the Windows XP Web site at http://www.microsoft.com

Foundation Network Companion Guide: Deploying 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2

Deploying 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2

This is a companion guide to the Windows Server® 2008 Foundation Network Guide, which is available for download in Word format at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=105231) and in HTML format in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=106252).

The Windows Server 2008 Foundation Network Guide provides instructions for planning and deploying the core components required for a fully functioning network and a new Active Directory® Domain Services (AD DS) domain in a new forest.

This guide explains how to build upon a foundation network by providing instructions about how to deploy Institute of Electrical and Electronics Engineers (IEEE) 802.1X-authenticated IEEE 802.11 wireless access using Protected Extensible Authentication Protocol – Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2).

Because PEAP-MS-CHAP v2 requires that users provide password-based credentials rather than a certificate during the authentication process, it is easier and less expensive to deploy than EAP-TLS or PEAP-TLS.

Note
In this guide, IEEE 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2 is abbreviated to “wireless access.”

About this guide

This guide provides instructions on how to deploy a WiFi access infrastructure using PEAP-MS-CHAP v2 and the following components:

• One or more 802.1X-capable 802.11 wireless access points (APs).
  
  
• Active Directory Users and Computers.
  
  
• Group Policy Management.
  
  
• One or more Network Policy Server (NPS) servers.
  
  
• Server certificates for computers running NPS.
  
  
• Wireless client computers running Windows Vista or Windows XP with Service Pack 2.
  
  

This guide is designed for network and system administrators who have:

• Followed the instructions in the Windows Server 2008 Foundation Network Guide to deploy a foundation network, or for those who have previously deployed the core technologies included in the foundation network, including AD DS, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS).
  
  
• Either followed the instructions in the Windows Server 2008 Foundation Network Companion Guide: Deploying Server Certificates to deploy and use Active Directory Certificate Services (AD CS) to autoenroll server certificates to computers running NPS, or who have purchased a server certificate from a public CA, such as VeriSign, that client computers already trust. A client computer trusts a CA if that CA cert is already in the Trusted Root Certification Authorities certificate store on Windows-based computers. By default, computers running Windows have multiple public CA certificates installed in their Trusted Root Certification Authorities certificate store.
  
  The Foundation Network Companion Guide: Deploying Server Certificates is available for download in Word format at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=108259) and in HTML format in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=108258).
  
  

It is recommended that you review the design and deployment guides for each of the technologies that are used in this deployment scenario. These guides can help you determine whether this deployment scenario provides the services and configuration that you need for your organization's network.

Requirements

Following are the requirements for deploying a wireless access infrastructure by using the scenario documented in this guide:

• Before deploying this scenario, you must first purchase and install 802.1X-capable wireless access points to provide wireless coverage in the desired locations at your site.
  
  
• Active Directory Domain Services (AD DS) is installed, as are the other network technologies, according to the instructions in the Windows Server 2008 Foundation Network Guide.
  
  
• Server certificates are required when you deploy the PEAP-MS-CHAP v2 certificate-based authentication method.
  
  
• You or someone else in your organization is familiar with the IEEE 802.11 standards that are supported by your wireless APs and the wireless network adapters installed in the client computers on your network; for example, radio frequency types, 802.11 wireless authentication (WPA2 or WPA), and ciphers (AES or TKIP). For information about determining which wireless standards are supported on wireless client computers running Windows Vista and Windows Server 2008.
  
  

What this guide does not provide

Following are some items this guide does not provide:

Comprehensive guidance for selecting 802.1X-capable wireless access points

Because many differences exist between brands and models of 802.1X-capable wireless APs, this guide does not provide detailed information about:

• Determining which brand or model of wireless AP is best suited to your needs.
  
  
• The physical deployment of wireless APs on your network.
  
  
• Advanced wireless AP configuration, such as for wireless VLAN.
  
  
• Instructions on how to configure wireless AP vendor-specific attributes in NPS.
  
  

Additionally, terminology and names for settings vary between wireless AP brands and models, and might not match the generic setting names referenced in this guide. For wireless AP configuration details, you must review the product documentation provided by the manufacturer of your wireless APs.

Instructions for deploying NPS server certificates

There are two alternatives for deploying NPS server certificates. This guide does not provide comprehensive guidance to help you determine which alternative will best meet your needs. In general, however, the choices you face are:

• Purchasing certificates from a public CA, such as VeriSign, that is already trusted by Windows-based clients. This option is typically recommended for smaller networks.
  
  
  • Advantages:
    
    
    • Installing purchased certificates does not require as much specialized knowledge as deploying a private CA on your network, and can be easier to deploy in networks that have only a few NPS servers.
      
      
    • Using purchased certificates can prevent specific security vulnerabilities that can exist if the proper precautions are not taken when deploying a private CA on your network.
      
      
  • Disadvantages:
    
    
    • This solution does not scale as well as deploying a private CA on your network. Because you must purchase a certificate for each NPS server, your deployment costs increase with each NPS server you deploy.
      
      
    • Purchased certificates have recurring costs, because you must renew certificates prior to their expiration date.
      
      
• Deploying a private CA on your network by using AD CS.
  
  
  • Advantages:
    
    
    • AD CS is included with Windows Server 2008.
      
      
    • This solution scales very well. After you have deployed a private CA on your network, AD CS automatically issues certificates to all NPS servers in your domain with no incremental increases in cost, even if you later add NPS servers to your network.
      
      
    • AD CS automatically issues a server certificate to new NPS servers that you add to your network.
      
      
    • If you later decide to change your authentication infrastructure from secure password authentication using PEAP to one that requires client certificates and uses either EAP-TLS or PEAP-TLS, you can do so by using your AD CS-based private CA.
      
      
  • Disadvantages:
    
    
    • Deploying a private CA on your network requires more specialized knowledge than purchased certificates, and can be more difficult to deploy.
      
      
    • It is possible to expose your network to specific security vulnerabilities if the proper precautions are not taken when deploying a private CA on your network.
      
      

NPS network policies and other NPS settings

Except for the configuration settings made when you run the Configure 802.1X wizard, as documented in this guide, this guide does not provide detailed information for manually configuring NPS conditions, constraints or other NPS settings.

For more information about NPS, see Additional Resources in this guide.

DHCP

This deployment guide does not provide information about designing or deploying DHCP subnets for wireless LANs.

For more information about DHCP, see the Additional Resources in this guide.

Technology overviews

Following are technology overviews for deploying wireless access:

IEEE 802.1X

The IEEE 802.1X standard defines the port-based network access control that is used to provide authenticated network access to Ethernet networks. This port-based network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard was designed for wired Ethernet networks, it has been adapted for use on 802.11 wireless LANs.

802.1X-capable wireless access points (APs)

This scenario requires the deployment of one or more 802.1X-capable wireless APs that are compatible with the Remote Authentication Dial-In User Service (RADIUS) protocol.

802.1X and RADIUS-compliant APs, when deployed in a RADIUS infrastructure with a RADIUS server such as an NPS server, are called RADIUS clients.

Wireless clients

This guide provides comprehensive configuration details to supply 802.1X authenticated access for domain-member users who connect to the network with wireless client computers running either Windows Vista or Windows XP with Service Pack 2 or later. Computers must be joined to the domain in order to successfully establish authenticated access.

If you are using computers running Windows Server 2008 as client computers, you can provision 802.1X security and connectivity settings on those computers by using the same Group Policy extension of Windows Vista Wireless Network (IEEE 802.1) Policies as for computers running Windows Vista. If you are using computers running Windows Server 2003 as client computers, you can provision 802.1X security and connectivity settings on those computers by using the same Group Policy extension of Windows XP Wireless Network (IEEE 802.1) Policies as for computers running Windows XP.

Active Directory Doman Services (AD DS)

AD DS provides a distributed database that stores and manages information about network resources and application-specific data from directory-enabled applications. Administrators can use AD DS to organize elements of a network, such as users, computers, and other devices, into a hierarchical containment structure. The hierarchical containment structure includes the Active Directory forest, domains in the forest, and organizational units (OUs) in each domain. A server that is running AD DS is called a domain controller.

AD DS contains the user accounts, computer accounts, and account properties that are required by IEEE 802.1X and PEAP-MS-CHAP v2 to authenticate user credentials and to evaluate authorization for wireless connections.

Active Directory Users and Computers

Active Directory Users and Computers is a component of AD DS that contains accounts that represent physical entities, such as a computer, a person, or a security group. A security group is a collection of user or computer accounts that administrators can manage as a single unit. User and computer accounts that belong to a particular group are referred to as group members.

Group Policy Management

Group Policy Management is a Windows Server 2008 feature that enables directory-based change and configuration management of user and computer settings, including security and user information. You use Group Policy to define configurations for groups of users and computers. With Group Policy, you can specify settings for registry entries, security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. The Group Policy settings that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory system containers—sites, domains, and OUs—you can apply the GPO's settings to the users and computers in those Active Directory containers. To manage Group Policy objects across an enterprise, you can use the Group Policy Management Editor Microsoft Management Console (MMC).

This guide provides detailed instructions about how to specify settings in the Wireless Network (IEEE 802.11) Policies Group Policy Management extension, which in turn configures the necessary settings on wireless client computers for 802.1X authenticated wireless access.

Server certificates

This deployment scenario requires server certificates for each NPS server that performs 802.1X authentication.

A server certificate is a digital document that is commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing CA, and they can be issued for a user, a computer, or a service.

A certification authority (CA) is an entity responsible for establishing and vouching for the authenticity of public keys belonging to subjects (usually users or computers) or other CAs. Activities of a certification authority can include binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and revoking certificates.

Active Directory Certificate Services (AD CS) is a Windows Server 2008 server role that issues certificates as a network CA. An AD CS certificate infrastructure, also known as a public key infrastructure (PKI), provides customizable services for issuing and managing certificates for the enterprise.

EAP, PEAP, and PEAP-MS-CHAP v2

Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing additional authentication methods that use credential and information exchanges of arbitrary lengths. With EAP authentication, both the network access client and the authenticator (such as the NPS server) must support the same EAP type for successful authentication to occur. Windows Server 2008 includes an EAP infrastructure, supports two EAP types, and the ability to pass EAP messages to NPS servers. By using EAP, you can support additional authentication schemes, known as EAP types. The EAP types that are supported by Windows Server 2008 are:

• Transport Layer Security (TLS)
  
  
• Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2)
  
  

Security Note
Strong EAP types (such as those that are based on certificates) offer better security against brute-force attacks, dictionary attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP version 1).

Protected EAP (PEAP) uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as an NPS server or other RADIUS servers. PEAP does not specify an authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MS-CHAP v2) that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients that are connecting to your organization's network through the following types of network access servers (NASs):

• 802.1X-capable wireless access points
  
  
• 802.1X-capable authenticating switches
  
  
• Computers running Windows Server 2008 and the Routing and Remote Access service (RRAS) that are configured as virtual private network (VPN) servers
  
  
• Computers running Windows Server 2008 and Terminal Services Gateway
  
  

PEAP-MS-CHAP v2 is easier to deploy than EAP-TLS because user authentication is performed by using password-based credentials (user name and password), instead of certificates or smart cards. Only NPS or other RADIUS servers are required to have a certificate. The NPS server certificate is used by the NPS server during the authentication process to prove its identity to PEAP clients.

This guide provides instructions to configure your wireless clients and your NPS server(s) to use PEAP-MS-CHAP v2 for 802.1X authenticated access.

Network Policy Server

Network Policy Server (NPS) allows you to centrally configure and manage network policies by using the following three components: Remote Authentication Dial-In User Service (RADIUS) server, RADIUS proxy, and Network Access Protection (NAP) policy server. NPS is an optional service of a foundation network, but it is required to deploy 802.1X wireless access.

When you configure your 802.1X wireless access points as RADIUS clients in NPS, NPS processes the connection requests sent by the APs. During connection request processing, NPS performs authentication and authorization. Authentication determines whether the client has presented valid credentials. If NPS successfully authenticates the requesting client, then NPS determines whether the client is authorized to make the requested connection, and either allows or denies the connection. This is explained in more detail as follows:

Authentication

Successful mutual PEAP-MS-CHAP v2 authentication has two main parts:

1. The client authenticates the NPS server. During this phase of mutual authentication, the NPS server sends its server certificate to the client computer so that the client can verify the NPS server's identity with the certificate. To successfully authenticate the NPS server, the client computer must trust the CA that issued the NPS server certificate. The client trusts this CA when the CA’s certificate is present in the Trusted Root Certification Authorities certificate store on the client computer.
   
   If you deploy your own private CA, the CA certificate is automatically installed in the Trusted Root Certification Authorities certificate store for the Current User and for the Local Computer when Group Policy is refreshed on the domain member client computer. If you decide to deploy server certificates from a public CA, ensure that the public CA certificate is already in the Trusted Root Certification Authorities certificate store.
   
   
2. The NPS server authenticates the user. After the client successfully authenticates the NPS server, the client sends user’s password-based credentials to the NPS server, which verifies the user’s credentials against the user accounts database in Active Directory Doman Services (AD DS).
   
   

If the credentials are valid, the server running NPS proceeds to the authorization phase of processing the connection request. Otherwise, NPS sends an Access Reject message and the connection request is terminated.

Authorization

The server running NPS performs authorization as follows:

• NPS checks for restrictions in the user or computer account dial-in properties in AD DS.
  
  
• NPS then processes its network policies to find a policy that matches the connection request. If a matching policy is found, NPS either grants or denies the connection based on that policy’s configuration.
  
  

If both authentication and authorization are successful, NPS grants access to the network, and the user and computer can connect to network resources for which they have permissions.

To deploy wireless access, you must configure NPS network policies. This guide provides instructions to use the Configure 802.1X wizard in NPS to create NPS policies for 802.1X authenticated wireless access.

Bootstrap profiles

For deployments in which the user or IT administrator cannot physically connect a computer to the wired Ethernet network to join the computer to the domain, and the computer does not have the necessary issuing root CA certificate installed in its Trusted Root Certification Authorities certificate store, this guide describes how to configure wireless clients running Windows Vista with a temporary wireless connection profile, called a bootstrap profile, to connect to the wireless network. A bootstrap profile removes the requirement to validate the RADIUS server's computer certificate. This temporary configuration enables the wireless user to join the computer to the domain, at which time the Wireless Network (IEEE 802.11) Policies are applied. The appropriate root CA certificate is then installed on the computer, and one or more wireless connection profiles that enforce the requirement for mutual authentication is installed on the computer. After joining the computer to the domain and restarting the computer, the user can use a wireless connection to log on to the domain.

FOR YOUR CHILD

IS YOUR CHILD WORTHY?
“Whatever they grow up to be, they are still our children, and the one most important of all the things we can give to them is unconditional love. Not a love that depends on anything at all except that they are our children.”




LIFE IS GIVEN BY A PARENT




The price of greatness is responsibility.
If we wish to create a lasting peace we must begin with the children.

Insurance

Try the best

BE INSURED BE SAFE

ARE YOU INSURED ?

HEALTH IS WEALTH

WEIGHT LOSS IN THREE STEPS

For a better life:




ENJOY YOUR LIFE:




Changes in a few days

NETSH.EXE

Netsh.exe

Netsh.exe is a tool an administrator can use to configure and monitor Windows-based computers at a command prompt. With the Netsh.exe tool, you can direct the context commands you enter to the appropriate helper, and the helper then carries out the command. A helper is a Dynamic Link Library (.dll) file that extends the functionality of the Netsh.exe tool by providing configuration, monitoring, and support for one or more services, utilities, or protocols. The helper may also be used to extend other helpers.

MORE INFORMATION

You can use the Netsh.exe tool to perform the following tasks: Configure interf...

You can use the Netsh.exe tool to perform the following tasks:

* Configure interfaces.

* Configure routing protocols.

* Configure filters.

* Configure routes.

* Configure remote access behavior for Windows-based remote access routers that are running the Routing and Remote Access Server (RRAS) Service.

* Display the configuration of a currently running router on any computer.

* Use the scripting feature to run a collection of commands in batch mode against a specified router.

The syntax for the Netsh.exe tool is:

netsh [-r router name] [-a AliasFile] [-c Context] [Command | -f ScriptFile]

To display a list of subcontexts and commands that can be used in a context, type the context name followed by a space and a ? at the netsh> command prompt. For example, to display a list of subcontext and commands that can be used in the /routing context, type routing ? at the netsh> command prompt, and then press ENTER.

Contexts

Context strings are appended to the Netsh.exe tool command and are passed to an associated helper. The helper may have one or more entry points that map to contexts. Some of the contexts available in the Netsh.exe tool are:

Context Command: /dhcp

Result: Changes to the Dynamic Host Configuration Protocol (DHCP) context.

Context Command: /ras

Result: Changes to the Remote Access Server (RAS) context.

Context Command: /routing

Result: Changes to the routing context.

Context Command: /wins

Result: Changes to the Windows Internet Name Service (WINS) context.

Contexts may also nest within other contexts. For example, the following contexts operate within the netsh>ras context:

Context Command: /ip

Result: Changes to the Internet Protocol (IP) context.

Context Command: /ipx

Result: Changes to the Internetwork Packet Exchange (IPX) context.

Context Command: /netbeui

Result: Changes to the NetBios Enhanced User Interface (NETBEUI) context.

The following subcontexts operate within the netsh>routing ip context:

Context Command: /autodhcp

Result: Changes to the autodhcp subcontext.

Context Command: /dnsproxy

Result: Changes to the dnsproxy subcontext.

Context Command: /igmp

Result: Changes to the Internet Group Membership Protocol (IGMP) subcontext.

Context Command: /mib

Result: Changes to the Management Information Base (MIB) subcontext.

Context Command: /nat

Result: Changes to the Network Address Translation (NAT) subcontext.

Context Command: /ospf

Result: Changes to the Open Shortest Path First (OSPF) subcontext.

Context Command: /relay

Result: Changes to the relay subcontext.

Context Command: /rip

Result: Changes to the Routing Information Protocol (RIP) subcontext.

Back to the top

Netsh.exe Commands

The following additional commands can be used with the Netsh.exe tool:

NOTE: Optional parameters are shown in brackets ([ ]). Alternative entries are shown with a pipe (|) character between them.

Context Command: /?

Result: Displays help.

Context Command: /abort

Result: Discards any changes made in offline mode. No effect in online mode.

Context Command: /add helper DLL-name

Result: Installs the helper .dll file in netsh.exe.

Context Command: /alias [alias-name] [string1] [string2 ...]

Result: If /alias, lists all aliases. If /alias alias-name, displays the equivalent string. If /alias alias-name string1 string2 ..., sets alias-name to the specified strings.

Context Command: /bye

Result: Exits the program.

Context Command: /commit

Result: Commits any changes made in the offline mode to the router. No effect in the online mode.

Context Command: /delete helper .dll file name

Result: Removes the helper .dll file from Netsh.exe.

Context Command: /dump -file name

Result: Dumps or appends configuration to a text file.

Context Command: /exec script file name

Result: Loads the script file and executes commands from it.

Context Command: /exit

Result: Exits the program.

Context Command: /h

Result: Displays help.

Context Command: /help

Result: Displays help.

Context Command: /offline

Result: Sets the current mode to offline. Any changes made in this mode are saved, but require a "commit" or "online" command to be set in the router.

Context Command: /online

Result: Sets the current mode to online. Any changes in this mode are immediately reflected in the router.

Context Command: /popd

Result: Pops a context from the stack.

Context Command: /pushd

Result: Pushes current context onto the stack.

Context Command: /quit

Result: Exits the program.

Context Command: /set mode [mode =] online | offline

Result: Sets the current mode to online or offline.

Context Command: /show alias | helper | mode

Result: If /show alias, lists all defined aliases. If /show helper, lists all top-level helpers. If /show mode, shows the current mode.

Context Command: /unalias alias name

Result: Deletes the specified alias.

Back to the top

Helper Dynamic Link Libraries Files Available

Routing & Remote Access IP Configuration - Ipmontr.dll

Routing & Remote Access IPX Configuration - Ipxmontr.dll

Interface - Ifmon.dll

RAS - Rasmontr.dll

DHCP - Dhcpmon.dll

WINS - Winsmon.dll

Back to the top

Associated Registry Entries for Helper Dynamic Link Libraries Files

HKEY_LOCAL_MACHINE/Software/Microsoft/NetSh/

REG_SZ: Ipmontr.dll

REG_SZ: Ipxmontr.dll

REG_SZ: Ifmon.dll

REG_SZ: Rasmontr.dll

REG_SZ: Dhcpmon.dll

REG_SZ: Winsmon.dll

NOTE: If attempts to use Netsh dump - to dump configurations to a file does not work, try using the syntax: netsh dump >filename or path\filename, from a command line.

ICTFREELANCER OVER AND OUT

VPN

How to install virtual private networking (VPN) and how to create a new VPN connection in servers that are running Windows Server 2003.

With a virtual private network, you can connect network components through another network, such as the Internet. You can make your Windows Server 2003-based computer a remote-access server so that other users can connect to it by using VPN, and then they can log on to the network and access shared resources. VPNs do this by "tunneling" through the Internet or through another public network in a manner that provides the same security and features as a private network. Data is sent across the public network by using its routing infrastructure, but to the user, it appears as if the data is sent over a dedicated private link.


Overview of VPN
A virtual private network is a means of connecting to a private network (such as your office network) by way of a public network (such as the Internet). A VPN combines the virtues of a dial-up connection to a dial-up server with the ease and flexibility of an Internet connection. By using an Internet connection, you can travel worldwide and still, in most places, connect to your office with a local call to the nearest Internet-access phone number. If you have a high-speed Internet connection (such as cable or DSL) at your computer and at your office, you can communicate with your office at full Internet speed, which is much faster than any dial-up connection that uses an analog modem. This technology allows an enterprise to connect to its branch offices or to other companies over a public network while maintaining secure communications. The VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.

Virtual private networks use authenticated links to make sure that only authorized users can connect to your network. To make sure data is secure as it travels over the public network, a VPN connection uses Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) to encrypt data.

Components of a VPN
A VPN in servers running Windows Server 2003 is made up of a VPN server, a VPN client, a VPN connection (that portion of the connection in which the data is encrypted), and the tunnel (that portion of the connection in which the data is encapsulated). The tunneling is completed through one of the tunneling protocols included with servers running Windows Server 2003, both of which are installed with Routing and Remote Access. The Routing and Remote Access service is installed automatically during the installation of Windows Server 2003. By default, however, the Routing and Remote Access service is turned off.
The two tunneling protocols included with Windows are:
• Point-to-Point Tunneling Protocol (PPTP): Provides data encryption using Microsoft Point-to-Point Encryption.
• Layer Two Tunneling Protocol (L2TP): Provides data encryption, authentication, and integrity using IPSec.
Your connection to the Internet must use a dedicated line such as T1, Fractional T1, or Frame Relay. The WAN adapter must be configured with the IP address and subnet mask assigned for your domain or supplied by an Internet service provider (ISP). The WAN adapter must also be configured as the default gateway of the ISP router.

NOTE: To turn on VPN, you must be logged on using an account that has administrative rights.
How to install and Turn on a VPN Server

To install and turn on a VPN server, follow these steps:

1. Click Start, point to Administrative Tools, and then click Routing and Remote Access.

2. Click the server icon that matches the local server name in the left pane of the console. If the icon has a red circle in the lower-left corner, the Routing and Remote Access service has not been turned on. If the icon has a green arrow pointing up in the lower-left corner, the Routing and Remote Access service has been turned on. If the Routing and Remote Access service was previously turn on, you may want to reconfigure the server. To reconfigure the server:
a. Right-click the server object, and then click Disable Routing and Remote Access. Click Yes to continue when you are prompted with an informational message.
b. Right-click the server icon, and then click Configure and Enable Routing and Remote Access to start the Routing and Remote Access Server Setup Wizard. Click Next to continue.
c. Click Remote access (dial-up or VPN) to turn on remote computers to dial in or connect to this network through the Internet. Click Next to continue.

3. Click to select VPN or Dial-up depending on the role that you intend to assign to this server.

4. In the VPN Connection window, click the network interface which is connected to the Internet, and then click Next.

5. In the IP Address Assignment window, click Automatically if a DHCP server will be used to assign addresses to remote clients, or click From a specified range of addresses if remote clients must only be given an address from a pre-defined pool. In most cases, the DHCP option is simpler to administer. However, if DHCP is not available, you must specify a range of static addresses. Click Next to continue.

6. If you clicked From a specified range of addresses, the Address Range Assignment dialog box opens. Click New. Type the first IP address in the range of addresses that you want to use in the Start IP address box. Type the last IP address in the range in the End IP address box. Windows calculates the number of addresses automatically. Click OK to return to the Address Range Assignment window. Click Next to continue.

7. Accept the default setting of No, use Routing and Remote Access to authenticate connection requests, and then click Next to continue. Click Finish to turn on the Routing and Remote Access service and to configure the server as a Remote Access server.

How to Configure the VPN Server
To continue to configure the VPN server as required, follow these steps.
How to Configure the Remote Access Server as a Router
For the remote access server to forward traffic properly inside your network, you must configure it as a router with either static routes or routing protocols, so that all of the locations in the intranet are reachable from the remote access server.

To configure the server as a router:
1. Click Start, point to Administrative Tools, and then click Routing and Remote Access.
2. Right-click the server name, and then click Properties.
3. Click the General tab, and then click to select Router under Enable this computer as a.
4. Click LAN and demand-dial routing, and then click OK to close the Properties dialog box.
How to Modify the Number of Simultaneous Connections
The number of dial-up modem connections is dependent on the number of modems that are installed on the server. For example, if you have only one modem installed on the server, you can have only one modem connection at a time.

The number of dial-up VPN connections is dependent on the number of simultaneous users whom you want to permit. By default, when you run the procedure described in this article, you permit 128 connections. To change the number of simultaneous connections, follow these steps:
1. Click Start, point to Administrative Tools, and then click Routing and Remote Access.
2. Double-click the server object, right-click Ports, and then click Properties.
3. In the Ports Properties dialog box, click WAN Miniport (PPTP), and then click Configure.
4. In the Maximum ports box, type the number of VPN connections that you want to permit.
5. Click OK, click OK again, and then close Routing and Remote Access.
How to Manage Addresses and Name Servers
The VPN server must have IP addresses available to assign them to the VPN server's virtual interface and to VPN clients during the IP Control Protocol (IPCP) negotiation phase of the connection process. The IP address assigned to the VPN client is assigned to the virtual interface of the VPN client.

For Windows Server 2003-based VPN servers, the IP addresses assigned to VPN clients are obtained through DHCP by default. You can also configure a static IP address pool. The VPN server must also be configured with name resolution servers, typically DNS and WINS server addresses, to assign to the VPN client during IPCP negotiation.


How to Manage Access
Configure the dial-in properties on user accounts and remote access policies to manage access for dial-up networking and VPN connections.

NOTE: By default, users are denied access to dial-up networking.


Access by User Account
To grant dial-in access to a user account if you are managing remote access on a user basis, follow these steps:
1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Right-click the user account, and then click Properties.
3. Click the Dial-in tab.
4. Click Allow access to grant the user permission to dial in. Click OK.
Access by Group Membership
If you manage remote access on a group basis, follow these steps:
1. Create a group with members who are permitted to create VPN connections.
2. Click Start, point to Administrative Tools, and then click Routing and Remote Access.
3. In the console tree, expand Routing and Remote Access, expand the server name, and then click Remote Access Policies.
4. Right-click anywhere in the right pane, point to New, and then click Remote Access Policy.
5. Click Next, type the policy name, and then click Next.
6. Click VPN for Virtual Private Access access method, or click Dial-up for dial-up access, and then click Next.
7. Click Add, type the name of the group that you created in step 1, and then click Next.
8. Follow the on-screen instructions to complete the wizard.


If the VPN server already permits dial-up networking remote access services, do not delete the default policy. Instead, move it so that it is the last policy to be evaluated.
How to Configure a VPN Connection from a Client Computer
To set up a connection to a VPN, follow these steps. To set up a client for virtual private network access, follow these steps on the client workstation:

NOTE: You must be logged on as a member of the Administrators group to follow these steps.

NOTE: Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

1. On the client computer, confirm that the connection to the Internet is correctly configured.
2. Click Start, click Control Panel, and then click Network Connections. Click Create a new connection under Network Tasks, and then click Next.
3. Click Connect to the network at my workplace to create the dial-up connection. Click Next to continue.
4. Click Virtual Private Network connection, and then click Next.
5. Type a descriptive name for this connection in the Company name dialog box, and then click Next.
6. Click Do not dial the initial connection if the computer is permanently connected to the Internet. If the computer connects to the Internet through an Internet Service Provider (ISP), click Automatically dial this initial connection, and then click the name of the connection to the ISP. Click Next.
7. Type the IP address or the host name of the VPN server computer (for example, VPNServer.SampleDomain.com).
8. Click Anyone's use if you want to permit any user who logs on to the workstation to have access to this dial-up connection. Click My use only if you want this connection to be available only to the currently logged-on user. Click Next.
9. Click Finish to save the connection.
10. Click Start, click Control Panel, and then click Network Connections.
11. Double-click the new connection.
12. Click Properties to continue to configure options for the connection. To continue to configure options for the connection,
follow these steps:

o If you are connecting to a domain, click the Options tab, and then click to select the Include Windows logon domain check box to specify whether to request Windows Server 2003 logon domain information before trying to connect.
o If you want the connection to be redialed if the line is dropped, click the Options tab, and then click to select the Redial if line is dropped check box.
To use the connection, follow these steps:

1. Click Start, point to Connect to, and then click the new connection.
2. If you do not currently have a connection to the Internet, Windows offers to connect to the Internet.
3. When the connection to the Internet is made, the VPN server prompts you for your user name and password. Type your user name and password, and then click Connect.
Your network resources must be available to you in the same way they are when you connect directly to the network.NOTE: To disconnect from the VPN, right-click the connection icon, and then click Disconnect.
Troubleshooting
Troubleshooting Remote Access VPNs
Cannot Establish a Remote Access VPN Connection
• Cause: The name of the client computer is the same as the name of another computer on the network.

Solution: Verify that the names of all computers on the network and computers connecting to the network are using unique computer names.
• Cause: The Routing and Remote Access service is not started on the VPN server.

Solution: Verify the state of the Routing and Remote Access service on the VPN server.

See Windows Server 2003 Help and Support Center for more information about how to monitor the Routing and Remote Access service, and how to start and stop the Routing and Remote Access service. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: Remote access is not turned on on the VPN server.

Solution: Turn on remote access on the VPN server.

See the Windows Server 2003 Help and Support Center for more information about how to turn on the remote access server. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: PPTP or L2TP ports are not turned on for inbound remote access requests.

Solution: Turn on PPTP or L2TP ports, or both, for inbound remote access requests.

See the Windows Server 2003 Help and Support Center for more information about how to configure ports for remote access. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The LAN protocols used by the VPN clients are not turned on for remote access on the VPN server.

Solution: Turn on the LAN protocols used by the VPN clients for remote access on the VPN server.

See the Windows Server 2003 Help and Support Center for more information about how to view properties of the remote access server. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: All of the PPTP or L2TP ports on the VPN server are already being used by currently connected remote access clients or demand-dial routers.

Solution: Verify that all of the PPTP or L2TP ports on the VPN server are already being used. To do so, click Ports in Routing and Remote Access. If the number of PPTP or L2TP ports permitted is not high enough, change the number of PPTP or L2TP ports to permit more concurrent connections.

See the Windows Server 2003 Help and Support Center for more information about how to add PPTP or L2TP ports. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN server does not support the tunneling protocol of the VPN client.

By default, Windows Server 2003 remote access VPN clients use the Automatic server type option, which means that they try to establish an L2TP over IPSec-based VPN connection first, and then they try to establish a PPTP-based VPN connection. If VPN clients use either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the VPN server.

By default, a computer running Windows Server 2003 Server and the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to zero.

Solution: Verify that the appropriate number of PPTP or L2TP ports is configured.

See the Windows Server 2003 Help and Support Center for more information about how to add PPTP or L2TP ports. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common authentication method.

Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common authentication method.

See the Windows Server 2003 Help and Support Center for more information about how to configure authentication. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common encryption method.

Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common encryption method.

See the Windows Server 2003 Help and Support Center for more information about how to configure encryption. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies.

Solution: Verify that the VPN connection has the appropriate permissions through dial-in properties of the user account and remote access policies. For the connection to be established, the settings of the connection attempt must:
o Match all of the conditions of at least one remote access policy.
o Be granted remote access permission through the user account (set to Allow access) or through the user account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission).
o Match all the settings of the profile.
o Match all the settings of the dial-in properties of the user account.
See the Windows Server 2003 Help and Support Center for an introduction to remote access policies, and for more information about how to accept a connection attempt. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The settings of the remote access policy profile are in conflict with properties of the VPN server.

The properties of the remote access policy profile and the properties of the VPN server both contain settings for:
o Multilink.
o Bandwidth allocation protocol (BAP).
o Authentication protocols.
If the settings of the profile of the matching remote access policy are in conflict with the settings of the VPN server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the Extensible Authentication Protocol - Transport Level Security (EAP-TLS) authentication protocol must be used and EAP is not enabled on the VPN server, the connection attempt is rejected.

Solution: Verify that the settings of the remote access policy profile are not in conflict with properties of the VPN server.

See the Windows Server 2003 Help and Support Center for more information about additional information about multilink, BAP and authentication protocols. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The answering router cannot validate the credentials of the calling router (user name, password, and domain name).

Solution: Verify that the credentials of the VPN client (user name, password, and domain name) are correct and can be validated by the VPN server.
• Cause: There are not enough addresses in the static IP address pool.

Solution: If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool. If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server cannot allocate an IP address, and the connection attempt is rejected. If all of the addresses in the static pool have been allocated, modify the pool. See the Windows Server 2003 Help and Support Center for more information about TCP/IP and remote access, and how to create a static IP address pool. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN client is configured to request its own IPX node number and the VPN server is not configured to permit IPX clients to request their own IPX node number.

Solution: Configure the VPN server to permit IPX clients to request their own IPX node number.

See the Windows Server 2003 Help and Support Center for more information about IPX and remote access. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN server is configured with a range of IPX network numbers that are being used elsewhere on your IPX network.

Solution: Configure the VPN server with a range of IPX network numbers that is unique to your IPX network.

See the Windows Server 2003 Help and Support Center for more information about IPX and remote access. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The authentication provider of the VPN server is improperly configured.

Solution: Verify the configuration of the authentication provider. You can configure the VPN server to use either Windows Server 2003 or Remote Authentication Dial-In User Service (RADIUS) to authenticate the credentials of the VPN client.

See the Windows Server 2003 Help and Support Center for more information about authentication and accounting providers, and how to use RADIUS authentication. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN server cannot access Active Directory.


Solution: For a VPN server that is a member server in a mixed-mode or native-mode Windows Server 2003 domain that is configured for Windows Server 2003 authentication, verify that:
o The RAS and IAS Servers security group exists. If not, create the group and set the group type to Security and the group scope to Domain local.
o The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.
o The computer account of the VPN server computer is a member of the RAS and IAS Servers security group. You can use the netsh ras show registeredserver command to view the current registration. You can use the netsh ras add registeredserver command to register the server in a specified domain.

If you add (or remove) the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (because of the way that Windows Server 2003 caches Active Directory information). To immediately effect this change, restart the VPN server computer.
o The VPN server is a member of the domain.
See the Windows Server 2003 Help and Support Center for more information about how to add a group, how to verify permissions for the RAS and IAS security group, and about netsh commands for remote access. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: A Windows NT 4.0-based VPN server cannot validate connection requests.

Solution: If VPN clients are dialing in to a VPN server running Windows NT 4.0 that is a member of a Windows Server 2003 mixed-mode domain, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the following command:
"net localgroup "Pre-Windows 2000 Compatible Access""
If not, type the following command at a command prompt on a domain controller computer, and then restart the domain controller computer:
net localgroup "Pre-Windows 2000 Compatible Access" everyone /add
See the Windows Server 2003 Help and Support Center for more information about Windows NT 4.0 remote access server in a Windows Server 2003 domain. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: The VPN server cannot communicate with the configured RADIUS server.

Solution: If you can reach your RADIUS server only through your Internet interface, do one of the following:
o Add an input filter and an output filter to the Internet interface for UDP port 1812 (based on RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)"). –or-
o Add an input filter and an output filter to the Internet interface for UDP port 1645 (for older RADIUS servers), for RADIUS authentication and UDP port 1813 (based on RFC 2139, "RADIUS Accounting"). -or-
o -or- Add an input filter and an output filter to the Internet interface for UDP port 1646 (for older RADIUS servers) for RADIUS accounting.
See the Windows Server 2003 Help and Support Center for more information about how to add a packet filter. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: Cannot connect to the VPN server over the Internet using the Ping.exe utility.

Solution: Because of the PPTP and L2TP over IPSec packet filtering that is configured on the Internet interface of the VPN server, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To turn on the VPN server to respond to ICMP (ping) packets, add an input filter and an output filter that permit traffic for IP protocol 1 (ICMP traffic).

See the Windows Server 2003 Help and Support Center for more information about how to add a packet filter. Click Start to access the Windows Server 2003 Help and Support Center.
Cannot Send and Receive Data
• Cause: The appropriate demand-dial interface has not been added to the protocol being routed.

Solution: Add the appropriate demand-dial interface to the protocol being routed.

See the Windows Server 2003 Help and Support Center for more information about how to add a routing interface. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: There are no routes on both sides of the router-to-router VPN connection that support the two-way exchange of traffic.

Solution: Unlike a remote access VPN connection, a router-to-router VPN connection does not automatically create a default route. Create routes on both sides of the router-to-router VPN connection so that traffic can be routed to and from the other side of the router-to-router VPN connection.

You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent VPN connections, you can turn on Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the VPN connection. For on-demand VPN connections, you can automatically update routes through an auto-static RIP update. See Windows Server 2003 online Help for more information about how to add an IP routing protocol, how to add a static route, and how to perform auto-static updates. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: A two-way initiated, the answering router as a remote access connection is interpreting router-to-router VPN connection.

Solution: If the user name in the credentials of the calling router appears under Dial-In Clients in Routing and Remote Access, the answering router may interpret the calling router as a remote access client. Verify that the user name in the credentials of the calling router matches the name of a demand-dial interface on the answering router. If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state.

See Windows Server 2003 online Help for more information about how to check the status of the port on the answering router, and how to check the status of the demand-dial interface. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: Packet filters on the demand-dial interfaces of the calling router and answering router are preventing the flow of traffic.

Solution: Verify that there are no packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of traffic. You can configure each demand-dial interface with IP and IPX input and output filters to control the exact nature of TCP/IP and IPX traffic that is permitted into and out of the demand-dial interface.

See Windows Server 2003 online Help for more information about how to manage packet filters. Click Start to access the Windows Server 2003 Help and Support Center.
• Cause: Packet filters on the remote access policy profile are preventing the flow of IP traffic.

Solution: Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the VPN server (or the RADIUS server if Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic. You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic permitted on the VPN connection. Verify that the profile TCP/IP packet filters are not preventing the flow of traffic.

ICTfreelancer over and out
mcse