Export (0) Print
Expand All

Protecting Windows RPC Traffic

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Updated : August 29, 2002

By Spyros Sakellariadis

On This Page

An Example of RPC Client-Server Communications
The Danger of Exposing RPC to the Internet
The ISA Solution
Are ISA RPCs safer?


In security circles, Remote Procedure Calls (RPCs) are bad news. "You might as well hang out a sign saying "I'm easy" wrote someone in an Internet newsgroup devoted to firewalls, railing against the idea of allowing servers to be accessed from the Internet using RPCs. According to a study by Cisco, "The most vulnerable Internet service, ranked by the percentage of times that the service was visible and found to have a security problem" is RPC, with 93.4 percent of the systems exposing RPC reporting security problems. (See References: Dangerous Internet Services). To be fair, in the SANS Institute's list of Internet Security Vulnerabilities, RPCs rank the highest only for UNIX systems, and are not even on the list for Windows ( ). Even CERT ( lists no major vulnerabilities for Windows 2000 RPCs. However, there have been exploits of the Windows RPC service or of other services accessed using Windows RPCs, and there is a prevalent notion in the Windows community that RPCs are evil and their use should be restricted.

The problem with this strategy, however, is that RPCs are really popular in software developer circles because they are very efficient and provide rich functionality. Consequently, many popular applications deployed widely in corporations use RPCs, and in an increasingly mobile world, the users of these applications are demanding that the corporation make them available over the Internet. Traditional secure remote access solutions, such as direct dial or Virtual Private Networks (VPNs), are costly or otherwise burdensome, so we have a quandary. How do you safely support RPC communications? This article discusses some of the perceptions and the realities of RPC vulnerabilities on the Windows platform, and the use of Microsoft's ISA server to address some of these issues.

An Example of RPC Client-Server Communications

To frame the discussion, we will examine one popular application that uses RPCs – Microsoft's Exchange Server, a corporate messaging server that supports a variety of clients. Users of standard email clients such as Outlook Express, Eudora, or Pegasus can access their mailboxes using the POP3 or IMAP4 protocols, and users of standard Internet browsers such as Internet Explorer or Netscape can read and send mail using the HTTP protocol. However, the majority of Exchange customers use the rich-featured Outlook client. When configured to talk natively to Exchange server, this Outlook client uses the MAPI protocol, which itself relies on RPCs to communicate with the different services on the Exchange server. A simple MAPI session between an Outlook client and an Exchange server is shown in Figure 1:


Figure 1: Outlook – Exchange communications

When the Outlook client first contacts the Exchange server, it connects using RPC to TCP port 135, to identify how to connect for different messaging and directory services. The Exchange server responds with the specific port numbers, and the Outlook client then connects to those ports using RPC and closes down its connection to port 135. From a security perspective, we need to understand what ports must to be exposed, and how they are used. Let's look at this in more detail.

Exchange Server Awaiting Connections

You can see the listening ports and open sessions on a Windows 2000 server using the command line utility NETSTAT -NA. You can also see this information from a remote server using any number of commercial or freely available port-scanning tools. A fragment of a NETSTAT output is shown in Listing 1:

Listing 1 Exchange NETSTAT –NA output






















This server has a network address of, and the fragment in Listing 1 shows that it is listening on all network interfaces (shown by a local address of on several TCP/UDP ports, and on the one network interface on a single TCP port. A full analysis of the entire NETSTAT output would show that this Windows and Exchange server is listening on the following ports:

Table 1 Exchange TCP/UDP ports
























RPC Port Mapper




NetBIOS Name Service




NetBIOS Datagram Service




NetBIOS Session Service












SMB for Netlogon








SMTP/LSA (tcp) routing agent



1024+ (95 high ports)




This server is providing various non-Exchange services, such as DNS and Authentication. For messaging, it is listening on TCP ports 25 (for inbound SMTP), 80/443 (for Outlook Web Access clients using HTTP and HTTPS), and 110 (POP3). It is also listening on 95 ports above 1024, only a few of which are well-known (e.g. 3389 for Terminal Services over RDP).

You can get additional information about what is on this server, and the function of the high ports, by querying TCP port 135. The Windows 2000 Endpoint Mapper or Location Service listens on this port for RPC requests for information about where to connect for specific services. When a program such as Exchange loads on a server, it registers a unique identifier for each service it provides, and tells the Endpoint Mapper where those services can be accessed. It identifies those services by a unique identifier known as a UUID. Exchange 2000 registers numerous services with the Endpoint Mapper for connections from MAPI messaging clients – three central ones are shown in Table 2:

Table 2 Exchange UUIDs

Service Interface


MS Exchange Directory RFR


MS NT Directory NSP


Exchange Server STORE EMSMDB


When an Outlook client wants to access one of those Exchange services, it sends an RPC query to TPC port 135 with the UUID of the service, and the Endpoint Mapper responds with the information. You can see a listing of all the services registered with the Endpoint Mapper on a Windows 2000 server using the command line utility RPCDUMP from the Windows 2000 Resource Kit. A partial listing of the RPCDUMP output is shown in Listing 2:

Listing 2 RPCDUMP output

Querying Endpoint Mapper Database... 
213 registered endpoints found. 
Annotation:Exchange Server STORE EMSMDB Interface 
VersMajor 0  VersMinor 81 
Annotation:Messenger Service 
VersMajor 1  VersMinor 0 

As this server is providing various non-Exchange services, it is advertising numerous RPC endpoints – a total of 213 services, in fact. As you can see, an RPCDUMP provides a lot more information than a NETSTAT command: NETSTAT tells you which ports the server is listening on, whereas an RPCDUMP tells you what is listening there and how to access it. For example, you can see from the information in Listing 2 that the Exchange STORE service (UUID a4f1db00… ) is listening on Endpoint (TCP port) 1248. An inspection of the NESTAT output on the Exchange Server confirms that the server is indeed listening on port 1248 – now we know why. If you analyzed all the 213 endpoints of the RPCDUMP, you would have an explanation of the function of many of the 95+ high-ports identified in Table 1.

Outlook Client Connection

We can see how these TCP/UDP ports are used by a messaging client by examining a network trace of an Outlook/Exchange session. When an Outlook client initially loads, it has no knowledge of where to find the Information store service on the Exchange server, and hence its mailbox. Listing 3 is an extract from a network monitor trace showing the process of Outlook querying TCP port 135 to discover how to connect to the Information Store service to access its mailbox:

Listing 3 Network Trace of Outlook connection

Frame 55 MSRPC c/o RPC Bind: UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA   
call 0x1  assoc grp 0x0  xmit 0x16D0  recv 0x16D0 SPOTS VALENTINA IP  
TCP: .... src:12853  dst:  135  
Frame 56 MSRPC c/o RPC Bind Ack:  
call 0x1  assoc grp 0x14A6D  xmit 0x16D0  recv 0x16D0 VALENTINA SPOTS IP  
TCP: .... src:  135  dst:12853  
Frame 57 MSRPC c/o RPC Request:       
call 0x1  opnum 0x3  context 0x0  hint 0x84 SPOTS VALENTINA IP  
TCP: .... src:12853  dst:  135  
Frame 58 MSRPC c/o RPC Response:      
call 0x1  context 0x0  hint 0x80  cancels 0x0 VALENTINA SPOTS IP  
TCP: .... src:  135  dst:12853  
Frame 66 MSRPC c/o RPC Bind:         UUID A4F1DB00-CA47-1067-B31F-00DD010662DA   
call 0x1  assoc grp 0x0  xmit 0x16D0  recv 0x16D0 SPOTS VALENTINA IP  
TCP: .... src:12854  dst: 1248  
Frame 67 MSRPC c/o RPC Bind Ack:      
call 0x1  assoc grp 0x2CE28  xmit 0x16D0  recv 0x16D0 VALENTINA SPOTS IP  
TCP: .... src: 1248  dst:12854  

The details of each frame have been omitted from Listing 3, so as not to obscure the nature of the transactions. What's going on in these frames? Here is a brief analysis:

  • Frame 55: The UUID of the RPC Endpoint Mapper is always E1AF8308-5D1F-11C9-91A4-08002B14A0FA. In this frame, the Outlook client SPOTS is making an RPC connection to TCP port 135 (dst: 135) of the Windows Server VALENTINA, and binding to the Endpoint Mapper service (RPC Bind: UUID E1AF8308…).

  • Frame 56: The Windows 2000 server acknowledges the Bind with a BindAck. We now have an RPC connection between SPOTS and VALENTINA's Endpoint Mapper.

  • Frame 57: The Outlook client is using RPC to ask the Endpoint Mapper for the service location of the Information store, identified by its UUID of A4F1DB00… It includes this UUID at offset 73 of the frame, with high/low bytes reversed. The detail of Frame 57 is as follows (highlighted in blue):


  • Frame 58: The Windows 2000 server responds with the data, at offset BE of the frame. It tells the Outlook client that the Information Store service is listening on port 1248 (04 E0 hex). The return also reverses the high/low bytes, as shown in the following detail of Frame 58:


  • Frame 66: The Outlook client is making an RPC connection to TCP port 1248 (dst: 1248) of the Windows Server, and binding to the Exchange Information Store service (RPC Bind: UUID A4F1DB00…).

  • Frame 67: The Windows 2000 server acknowledges the RPC Bind, and the Outlook client is now talking directly with the Exchange Information Store service. At this time, the Outlook client will close the connection to TCP/135.

Finally, you can see these connections with NETSTAT as well. Listing 4 shows the relevant connections just after the Outlook client connects (the Exchange server has an IP address of, and the Outlook client has an IP address of

Listing 4 Exchange NETSTAT –NA output













The initial connection between the Outlook client and the Exchange server on TCP port 135 is still showing, but listed as "TIME_WAIT", meaning that it is not currently being used. In a few moments, port 135's status will be changed to LISTENING, and only connections left as ESTABLISHED are the three connections to 1112, 1026, and 1248. All further communications between Outlook and Exchange take place over these connections.

The Danger of Exposing RPC to the Internet

So what is dangerous about disclosing that you are using RPC? We might group the dangers into four categories:

  • Endpoint Mapper promiscuity,

  • General Denial-of-Service (DoS) by attacking port 135 itself,

  • Service specific attacks based upon information from querying port 135, and

  • Escalation of privilege attacks based upon information from querying port 135.

Let's look at each in turn.

First, the Endpoint Mapper is highly promiscuous. A standard security maxim is that people should have access only to the information they need, and the Endpoint Mapper is a prime violator of this maxim. From preceding section we see that there are tools that allow you unfettered access to information:

  • NETSTAT and easily-available port scanners can show you TCP ports on which the server is listening.

  • RPCDUMP queries TCP/135 and shows you what RPC-based programs are registered on the server and the ports they are listening on.

The standard ports, such as TCP/25 (SMTP), TCP/53 (DNS), or TCP/80 (HTTP) can be shut down if you do not need them, or carefully managed and monitored if you do need them. If a malicious user runs a port-scanner program against your server, he will only find out about ports you are intentionally exposing to the Internet and protecting. However, if he uses a program such as RPCDUMP, and you expose even one RPC-based program to the Internet, he will find out about all RPC-based programs on your server whether you intend to expose them or not. The reason for this is that you have to expose the RPC Endpoint Mapper (since RPC based programs first access to the RPC Endpoint Mapper on TCP/135 before accessing their program-specific RPC port) – as we saw in the previous section, Outlook needs to access TCP/135 to find out where to access its mailbox. Unfortunately, you cannot stop the Endpoint Mapper answering a question about other RPC services, since it needs to be able to respond to queries from those clients. Consequently, allowing access to port TCP/135 for even one service (e.g. Exchange) divulges much more information (e.g. about Active Directory, SQL Server, or Systems Management Server) than you should. Traditionally there has been no way to address this problem.

Second, a hacker might create a generic DoS by attacking port 135 itself. If you can cause the RPC Endpoint Mapper that is listening on port 135 to fail, any RPC program that accesses that port first will be unable to determine what port to use for subsequent communications. Consequently, a successful attack on port 135 would block all RPC-based services offered by the server. The RPC Endpoint Mapper has in fact been compromised in the past. For example, a well-publicized vulnerability of the Windows NT 4.0 RPC was a flaw that caused it to fail upon receipt of a particular malformed request (See References: MS01-048). Microsoft rapidly issued a patch to protect against this exploit, and no similar flaws have been identified since then. However, from a hacker's point of view, attacking port 135 is highly profitable as a single-point-of-failure for all RPC services on the server.

Third, there could be service-specific attacks based upon information from querying port 135. If you expose port 135, a program such as RPCDUMP will tell you what services are running on the server. A malicious hacker might then attempt various attacks on the identified services – such as those offered by Exchange 2000 and SQL Server. This strategy has been exploited in the past. (For example, see References: MS01-041) As with MS01-048, Microsoft rapidly issued a patch for the affected servers and services, and there are no outstanding RPC vulnerabilities. However, given the amount of information that a general query to the RPC Endpoint Mapper divulges, a hacker will always probe here with glee.

Finally, since many management tools use RPC to administer the server or domain, there is also a possibility that someone could try an escalation-of-privilege attack through one of these ports. The security literature is rife with people concerned with this. A prevalent escalation-of-privilege attack was the "sechole" attack: under appropriate circumstances, a user with merely guest privileges could make himself a system administrator and have rights over your entire environment. (See References: SecHole.)The vulnerability was sufficiently well known, and SECHOLE.EXE sufficiently available, that companies such as Ernst and Young included a 'sechole' attack as part of their standard toolset when doing penetration analyses. (See References: Penetration Tools.) As before, a properly patched server is not vulnerable to any known escalation-of-privilege attack, but the strategy is there if some enterprising hacker discovers sechole2.

To drive home the need for concern about RPCs, let's look at one way to bring down a mail server through an RPC attack. Suppose a buffer overrun vulnerability on a specific Exchange RPC service was discovered, hacker mounted an attack on your server before you had a chance to patch it. One authority on secure coding practices describes the dangers thus:

The buffer overrun is one of the most dangerous and prevalent vulnerabilities in system code. At its core is an unchecked, externally provided buffer that causes some form of buffer operation (such as CopyMemory, strcat, strcpy, wcscpy, and so on) to fail. If you're lucky, the application will crash with a core dump, segmentation fault, or access violation. If you're not, an attacker can exploit the buffer overrun by injecting and executing arbitrary code in your process. Copying a buffer into a stack-based buffer is the most common cause of exploitable attacks. (See References: Testing For Buffer Overruns.)

The danger is clear – if you expose RPCs to the Internet, someone might exploit some relatively well known procedures that compromise your security.

The ISA Solution

Microsoft's ISA server includes a feature that allegedly allows you to expose RPC services to the Internet securely. The architecture is simple. For example, if you want to enable an Outlook client on the Internet to access an Exchange server using RPCs, you would do the following:

  • Set up Exchange Server as you would if there was no firewall or ISA server.

  • Install ISA server between the Exchange Server and the Internet.

  • On the Exchange server, setting the default gateway as the ISA server

  • On the ISA server, run the "Secure Mail Server" wizard to create a Server Publishing rule that uses the Exchange RPC filter to allow traffic from all Internet addresses to the Exchange Server.

  • In Outlook, use the IP address of the ISA server instead of the IP address of the Exchange Server to identify the location of your mailbox.

It is beyond the scope of this paper to describe exactly how to do this – the ISA documentation includes a full description of setting up "Server Publishing" rules for RPC servers, and there are several whitepapers on the Microsoft TechNet site at that give step-by-step details. At this stage, you could use Outlook from any location on the open Internet (for example, connected to an ISP from a hotel room) to access a mailbox on the Exchange server using RPCs.

At the time of writing, there was no detailed information published by Microsoft about the way the ISA RPC filter works. However, from network traces we can see the following. When the Outlook MAPI client tries to make a connection to the Exchange server, it contacts the RPC Endpoint Mapper on TCP/135 on the ISA server. If the RPC packet contains the correct UUID for an Exchange Service, the ISA service sends an RPC packet to TCP/135 of the Exchange server identified in the Server Publishing Rule. The Exchange server's Endpoint Mapper then responds to the ISA server with the port number it wants used for subsequent connections (e.g. 1248), and the ISA server responds to the Outlook client with the port number the ISA server wants used (e.g. 3500). It is important to note that the port number that the Exchange Server tells the ISA server is not the same port number as the ISA server tells the Outlook client. (In fact, even if you configure Exchange Server to use static high ports instead of dynamic to talk to ISA, the ISA server will still use dynamic ports to talk to Outlook. Conversely, you can leave Exchange using dynamic ports, but force ISA to use static ports.) In our example, the Outlook client talks to ISA on port 1248, thinking it is talking to Exchange. In reality, ISA is talking to Exchange on port 3500, and forwarding the information back to Outlook. The same holds true for all the Exchange RPC services used by an Outlook client, shown earlier in Table 2. You can see a complete list of the RPC interfaces that are exposed by the Secure Mail Publishing functionality of ISA Server in the Microsoft Knowledge Base article 304948, available at:;en-us;304948

A report in 1999 by Sandia National Laboratories for the U.S. Department of Energy lamented the lack of an RPC proxy server that could "limit access to specific RPC services". (See References: Firewalling Windows NT.) Lacking specific documentation from Microsoft about how ISA server works, we cannot verify that it is a proxy or reverse proxy server, but it certainly does appear to act that way. In particular, it does address the Sandia concern explicitly.

Are ISA RPCs safer?

Even amongst ISA aficionado's you can find people recanting the standard mantra about the evils of RPCs. For example, the eminence grise of ISA, Tom Shinder, published the definitive step-by-step article on how to set up the Server Publishing Rule discussed above, but still felt he needed to issue the standard disclaimer:

"Generally, it's not a good idea to open RPC ports to Internet users. This will happen if you allow Incoming Microsoft Exchange/Outlook. If you have external clients that need to connect to an internal Exchange Server, they should establish a VPN connection with the ISA Server and then access the internal Exchange server." (See References: Publishing a Mail Server.)

These sorts of claims go counter to the Microsoft claims, that ISA makes publishing RPCs safe, and leave you wondering about the basis of the concerns. Above we identified four categories of RPC dangers, and it is illuminating to re-examine them with ISA in mind.

First, we had the issue of the promiscuity – the servers provided too much information when queried from the Internet. When we ran a port scanner against our Exchange server, we saw not only the expected well-known ports but also a series of high ports, which we might try to exploit. What happens when you run a port scanner against an ISA server publishing that same Exchange Server? Listing 5 shows the output:

Listing 5 Port scanner against ISA output


ISA server hides the high ports that we saw when we ran the port scanner against the Exchange server. In fact, as far as the port scanner can tell, the ISA server is not listening on any high ports, although it is listening on port 135. Earlier, when we prodded TCP/135 by running RPCDUMP against our Exchange server, we found some 213 Endpoints described in detail. What happens when you run RPCDUMP against an ISA Server publishing Exchange RPCs? Listing 6 shows the output:

Listing 6 RPCDUMP against ISA output

Querying Endpoint Mapper Database... 
RpcMgmtEpEltInqNext:(The remote procedure call failed. ). 
rpcdump failed after 1 seconds 

ISA server simply refuses to answer general RPC queries about what the ISA server is publishing! There is no information a malicious hacker can glean from Listings 5 or 6 about the services running on the ISA server, about services running on the servers behind the ISA server, or about the servers being published by ISA server. Rather than being promiscuous, the ISA server is very cagy with its information!

Second, we examined the concern that the Endpoint Mapper itself on the server can be attacked. While this is theoretically still true, it is neither obvious nor as important. Not as obvious, because ISA does not listen on TCP/135 the same way as regular servers do – you see this from its response to RPCDUMP. Consequently, it is not clear that attacking TCP/135 in the way that you would for a normal RPC Endpoint Mapper would have any affect on an ISA server. This is difficult to assess, since there are no known vulnerabilities of TCP/135, so we cannot confirm or refute this. However, it is also important to note that the affect of such an attack might not be as wide-ranging as the attack on TCP/135 of the Exchange server. If you can effectively neutralize TCP/135 on the ISA server, you have a DoS against Internet MAPI clients accessing the Exchange Server; you do not have a dead Exchange Server. Consequently, your enterprise clients are still able to access their mail, as are any Internet POP3, IMAP4, or OWA client. You basically have a perimeter defense which has closed access to your internal network on one port – not necessarily a bad thing at all.

Next, we discussed the concerns that a malicious hacker could use the information from an RPCDUMP to attack specific services running on the server or to mount an escalation-of-privilege attack. Both of these types of attacks are hindered because there is no information divulged by the initial query. For example if a hacker tried to query the Endpoint Mapper for a service on which to mount a buffer overrun attack, he would not get a response with a service location. For ISA to reply, you need to give it a properly formatted query with the UUID that you want. Suppose the hacker knew that you were running Exchange, and attempted a buffer overrun attack on every port above 1024, using the Exchange Server Store UUID. Ultimately, he would stumble across the correct port, with the correct UUID, but it is unlikely that this success will help him. The little ISA Server documentation that we do have indicates that the ISA server will not create a query of the Exchange service on the remote Exchange server unless the call from the Internet client is a correctly formulated and benign request. As with an attack on TCP/135 itself, the most probable worst case outcome is a DoS of the ISA server itself. That is not to say that determined hackers won't find ways to persuade ISA to proxy malicious requests, but we know of no such exploits right now. Furthermore, we have no reason to believe that such an exploit is possible.


It is foolish ever to claim that exposing anything to Internet access is totally 'safe'. However, we have seen that ISA server does eliminate many of the concerns people currently have about exposing RPCs to the Internet.

Sidebar: Tools and Utilities referenced in the text


Where found

Where used

What it does


Windows 2000 TCP/IP

Listing 1

Shows listening ports and open sessions on a Windows 2000 server


Windows 2000 Resource Kit

Listing 2

Shows services registered with the TCP Endpoint Mapper

Network Monitor

Mini version: Windows 2000 TCP/IP
Full version: SMS 2.0

Listing 3

Captures and displays full network traces. Useful for analyzing contents of network traffic. Use caution – many companies have regulations against running network traces internally.

Port scanner

Many commercial or shareware available. Search MSN for "port scanner"

Listing 5

Be very careful. Many companies have strict regulations against running port scanners internally or against their web sites. May be reported as a computer crime.


  1. Analyzing Exchange RPC Traffic Over TCP-IP (159298). Microsoft, June 21001. Available on the Microsoft Online Support site at;en-us;159298

  2. Attack and Penetration Tools and Techniques. Marty Walters, Earnst and Young, LLP, at or

  3. Best RPC Programming Practices. Microsoft Platform SDK, available on the Microsoft MSDN site at

  4. Denial of Service in Applications Using RPC over Named Pipes (195733). Microsoft, August 2001. Available on the Microsoft Online Support site at;EN-US;195733.

  5. Firewalling Windows NT: A Case Study. C. Douglas Brown, Sandia National Laboratories, May 1999. Available at

  6. How to Configure Internet Security and Acceleration Server to Publish an Internal Exchange Server. Available on the Microsoft Knowledge Base site at;en-us;308599 .

  7. Microsoft Security Bulletin MS01-041: Malformed RPC Request Can Cause Service Failure. Microsoft, July 2001. Available on the Microsoft TechNet site at

  8. Microsoft Security Bulletin MS01-048: Malformed Request to RPC Endpoint Mapper can Cause RPC Service to Fail. Microsoft, September 2001. Available on the Microsoft TechNet site at

  9. Publishing a Mail Server with ISA Server. Tom Shinder,, 2001. Available at

  10. RPC Interfaces That Are Exposed by Secure Mail Publishing in ISA Server 2000. Available on the Microsoft Knowledge Base site at;en-us;304948 .

  11. SecHole Lets Non-administrative Users Gain Debug Level Access to a System Process (190288). Microsoft, July 1998, Last Modified August 2001. Available on the Microsoft Online support Site at;EN-US;190288

  12. Testing for Buffer Overruns. Michael Howard, 2001. On the DevX site at

  13. Hacking at ISA: Test Plan and Results. Internal project notes for certifying ISA's use at USi. Amesh Mansukhani, John Kerr, Spyros Sakellariadis, unpublished, USinternetworking, 2001.

  14. What are the Most Dangerous Internet Services? Cisco, 2001. Available at

  15. Windows 2000 Startup and Logon Traffic Analysis. Available on the Microsoft TechNet web site at

  16. XADM: Setting TCP/IP Ports for Exchange and Outlook Client Connections Through a Firewall. Available on the Microsoft Online support Site at;EN-US;155831

  17. XCCC: How to Configure Exchange 2000 Conferencing Server and ISA Server to Allow Audio and Video. Available on the Microsoft Knowledge Base site at;en-us;303098 .

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

© 2016 Microsoft