June 30, 2008 9:48 AM PDT

Hyper-V is not hype

Posted by Jon Oltsik 7 comments

Microsoft did something that it rarely does last week when it announced availability of its Hyper-V server virtualization technology months ahead of schedule. Unlike Microsoft Virtual Server which ran as an application, Hyper-V is a true hypervisor capable of hosting multiple instances of Windows and even Suse Linux.

OK, so Microsoft is in the game, but can it compete with server virtualization king VMware? Yup. According to ESG Research, 69 percent of organizations planning to adopt server virtualization are considering Microsoft technology, 59 percent are considering VMware, 10 percent contemplating XenSource, and 4 percent are kicking the server virtualization tires with Virtual Iron.

Microsoft understands that server virtualization is a strategic IT initiative and it has the potential to really disrupt the server licensing landscape. In other words, server virtualization could take a bite out of Windows sales if VMware wins in a landslide. Microsoft just won't let that happen.

As Hyper-V gains visibility my colleague Mark Bowker expects Microsoft to:

1. Throw money and programs at its OEMs
Microsoft will use its vast resources to run joint-marketing programs, educate customers, and generate leads with server vendors like Dell, Hewlett-Packard, and IBM. The goal? Maximize visibility of Hyper-V in a hurry.

2. Use management as a Hyper-V complement
Microsoft is currently in beta with its System Center Virtual Machine Manager (SCVMM), a management platform that controls Hyper-V and VMware ESX. As this becomes available, Microsoft can play a low-cost management card to introduce its hypervisor into VMware accounts.

3. Target the midmarket
VMware is surprisingly strong in the SMB space, along with feisty Virtual Iron. Nevertheless, Microsoft has an army of channel partners and Windows consultants who should be able to quickly penetrate this windows-centric market segment.

VMware is way too ubiquitous and strong to be "Netscaped," but Microsoft will certainly make the server virtualization space more competitive--in a hurry.

Jon Oltsik is a senior analyst at the Enterprise Strategy Group.

Hyper-V is not hype | Tech news blog - CNET News.com

Server Publishing with ISA Server 2004/2006 and Route Relationship Between Networks

Suppose you have the following scenario:

You are running ISA Server in 3-Leg configuration with a route relationship between the Internal and Perimeter networks. There's a FTP Server and some Web Servers operating in your Perimeter network.

ISA IP-Addresses:

Internal 172.118.115.15

Perimeter 39.1.1.15

External 192.168.101.15

FTP Server Address is 39.1.1.5 connected to Perimeter network

You have already published some Web Servers connected to your Perimeter network, and made them available to External and Internal Users. Now you want to publish a Non-Web Server e.g. the FTP Server connected to the Perimeter network to the Users in the External and Internal networks. You want to use the ISA IP-Addresses for this publishing scenario.

To do so you open the ISA MMC right-click Firewall Policy and Select New ->'Non-Web Server Protocol publishing rule'. You Enter a Name for the rule e.g. "Publish Perimeter FTP Server to Internal and External", in the Next Window you enter the IP Address of the Server, e.g. 39.1.1.5, next you select the FTP-Server Protocol. Then you select on which networks and which IP-Addresses the ISA Server will listen for requests intended for the published FTP Server.

On the Next Page you Finish the Wizard and Apply the changes.

That's easy, isn't it?

Now you want to verify the access to the FTP Server.

You first check the access from External to IP 192.168.101.15, works fine.

Next you want to access the Server from your Internal network using IP 172.118.115.15... it doesn't work.

But why? You start troubleshooting, looking at the ISA Live Logging, and realize, that no ISA rule matches the requests and therefore the request is denied.

On the ISA Server start a command window (Start, Run, cmd), and check if there is a socket Listening to Port 21 using the command netstat -an | findstr 21

The Output shows, that there actually is a Listening socket for the configured External IP, but no socket for your Internal IP.

ISA Server provides a tool called fwengmon to analyze and troubleshoot firewall connectivity issues by monitoring ISA Server in kernel-mode driver (fweng.sys) (ISA 2006: http://www.microsoft.com/downloads/details.aspx?familyid=01fc5551-5d44-4a99-966a-bd86caeb43d7 or ISA 2004: http://www.microsoft.com/downloads/details.aspx?FamilyID=F3306399-D4F9-4989-865E-C61F8293C330).

You execute fwengmon.exe with the /C parameter to check the created objects and receive output similar to this:

The output shows, that ISA has created one socket for 39.1.1.5:21 (FTP Server IP) and one for your external IP 192.168.101.15:21, but no socket for your internal IP. This is called ISA 'port stealing' and represents the route relationship for the traffic.

Does ISA simply ignore the complete publishing rule? Why is there no internal socket, and why can ISA Server create sockets for IP Addresses not configured on ISA?

The Answer: ISA will only create sockets and bind them to ISA Servers owned IP-Addresses for Non-Web Server Protocol publishing rules when there is a NAT relationship between those networks.

If ISA recognizes that there is a route relationship between the networks ISA will not create a socket for the Server IP Address you want to publish. Therefore the access will work when you try to directly connect to the Server IP Address 39.1.1.5:21.

!NOTE! The Web Listener used for Web publishing will always include the ISA Web Proxy Filter. Because an application proxy mechanism such as the Web Proxy Filter creates a completely new connection between ISA and the published server, and because the default for Web Publishing rules is to “Use the ISA computer IP address” when creating these connection. Thus, ISA appears to perform NAT on the traffic between the client and server, because it creates sockets for its configured IP Addresses even if there is a route relationship between the networks.

Question - But for all that, is it possible to publish my FTP Server without changing the network relationship between Perimeter and Internal to NAT?

Answer - Yes, you can do this

To solve the issue, you have to create a new network rule.

1. Navigate to Configuration, right-click Networks and select New -> Network Rule.

2. Choose a Name, e.g. "Internal to Perimeter FTP Server"

3. Add the FTP Server to the Sources. Click Add, New/Computer and create a Computer Object for your FTP Server. Then select this Object to add it to the Sources.

4. Add your Internal network to the destinations.

5. Configure a Network Address Translation (NAT) relationship.

6. Finish the Wizard and verify that the new rule order is lower (numerically) than the rule defining the route relationship between Perimeter and Internal. Apply the changes.

7. After the changes have been applied, you can use fwengmon to verify that the socket has been created in Kernel Mode and use netstat -an to check if there is a listening socket.

You can see, that the socket for the 39.1.1.5:21 disappeared and a new socket for 172.118.115.15:21 is created.

8. When you verify the access from your Internal, you'll see, that you now can connect to the 172.118.115.15:21 and that the correct rule is being matched.

Philipp Sand | Support Specialist ISA Server

Published Tuesday, June 24, 2008 12:54 PM by isablog

Forefront TMG (ISA Server) Product Team Blog : Server Publishing with ISA Server 2004/2006 and Route Relationship Between Networks

Another Look at Web Publishing. Part II: Host Headers with SSL and Certificates

In Part I, I mentioned that separate TCP connections are established for conveying a Web request from a client to an ISA Server computer and for forwarding the request from the ISA Server computer to the published server. In this part, I’ll focus on some issues that need special attention when one or both of these connections must become an SSL connection for encrypted communication.

SSL Connections and SSL Bridging

Whenever ISA Server terminates or initiates an SSL connection on a segment between a client and a published Web server, we say that it performs SSL bridging. The following SSL bridging scenarios are possible:

· HTTPS-to-HTTPS bridging—A request arriving at the ISA Server computer on an SSL connection is forwarded to the published server over an SSL connection. In this scenario, both the client and ISA Server send encrypted requests.

· HTTPS-to-HTTP bridging—A request arriving at the ISA Server computer on an SSL connection is forwarded over an ordinary TCP connection. In this scenario, the client sends an encrypted request, and ISA Server sends an unencrypted request.

· HTTP-to-HTTPS bridging—An HTTP request arriving at the ISA Server computer is forwarded over an SSL connection. In this scenario, only ISA Server sends an encrypted request.

The client indicates that an SSL connection is required in the first segment by specifying the HTTPS protocol in the URL requested, and the properties of the Web publishing rule that applies to the client’s encrypted request (if there is a Web publishing rule with a Web listener that listens on the IP address and port to which the request is sent) determine whether an SSL connection is required between the ISA Server computer and the published server. Web requests that require an SSL connection are typically sent to port 443.

Whenever an SSL connection is required, the server, that is the ISA Server computer in the first segment and the published Web server in the second segment, must present a server certificate to prove its identity to the client during the SSL handshake. On the segment between the original client and the ISA Server computer, the SSL handshake can be completed successfully only if the common name on the certificate matches the host name in the URL requested. On the segment between the ISA Server computer and the published server, the SSL handshake can be completed successfully only if the common name on the certificate presented by the published server matches the name that is expected by ISA Server, which acts as the client here. In some cases, the SSL handshake can succeed if a subject alternate name on the certificate matches the required name, but this possibility is beyond the scope of this discussion.

In addition, for each SSL connection you can optionally require the client to present a certificate to prove its identity to the server, but this option is also beyond the scope of this discussion.

It is important to bear in mind here that the SSL handshake takes place after the TCP connection is established, but before the HTTP request message is sent. The HTTP request is sent as an encrypted message only after the SSL connection is established. In other words, the server must respond with the certificate before it receives the Host header in the HTTP GET request. The server has only the information received during the TCP handshake and the beginning of the SSL handshake. In particular, the server knows the IP address and port used to establish the TCP connection. If we confine this discussion to requests sent to port 443, the server must return the same certificate for all requests that arrive on the same IP address, even if they are destined for different Web sites.

From the Client to the ISA Server Computer

Let’s examine how this name matching can be achieved. When a client requests an SSL connection with an ISA Server computer, the ISA Server computer must present a certificate with a common name that matches the host name in the URL requested. The request can reach the ISA Server computer only if the host name in the URL requested is resolved to an IP address of the ISA Server computer, for example, by querying DNS. On the ISA Server computer, you can configure a Web listener to listen for requests from a specific network on a specific IP address and specify a certificate with a common name that matches the host name which resolves to this IP address. The appropriate certificate must be installed in the Personal store for the local computer on the ISA Server computer, and the client will trust this certificate only if the root certificate of the Certification Authority (CA) that issued the certificate is installed in the Trusted Root Certification Authorities store on the client computer.

In ISA Server 2006, you can publish multiple Web sites or applications on different IP addresses using the same Web listener. In this case, you can specify a different server certificate for each Web site. This is done by mapping a different server certificate to each IP address on which the Web listener listens. ISA Server will present the server certificate that is mapped to the IP address on which each request arrives. In ISA Server 2004, you can specify only one SSL server certificate in a Web listener.

If you are publishing multiple Web sites that have public names with the same DNS suffix, you can use a single IP address and a single Web listener to publish multiple sites by using a wildcard certificate. For example, if you want to publish Web sites with the resolvable public host names mail.contoso.com, news.contoso.com, and blogs.contoso.com, you can acquire a wildcard certificate for *.contoso.com and install it on the ISA Server computer. Clients sending requests for any of the host names just listed will accept a certificate with the common name *.contoso.com as a valid certificate.

From the ISA Server Computer to the Published Server

Now let’s move on to the SSL connection between the ISA Server computer and the internal server that hosts the published Web site, which must be listening on the port for forwarding Web requests that is specified in the applicable Web publishing rule (this port is typically 443). In this case, you need to configure your Web publishing rule to accept the common name on the certificate that will be presented by the published server. For a single published server, this means that the name of the published server (ISA Server 2004) or the internal site name (ISA Server 2006) specified on the To tab of the Web publishing rule must match the common name on the certificate that will be presented by the published server. In ISA Server 2004, this name must be resolvable to the IP address of the published server because ISA Server 2004 uses this IP address to establish the TCP connection with the published server. In ISA Server 2006, if your ISA Server computer cannot resolve the internal site name to the IP address of the published server, you can select Computer name or IP address, and then type the required IP address or a name that can be resolved by the ISA Server computer.

Thus, ISA Server 2006 offers you a simple way to use the same certificate on the published server and your ISA Server computer. You can do this by requesting the certificate from a commercial CA on the internal Web server, installing it on the internal Web server, exporting it along with its private key, and then importing it to your ISA Server computer. In this case, the common name on the certificate will be identical to the host name that the original client provides in the URL. This can also be done on ISA Server 2004, but the procedure, which is publicly available, is a bit more complicated.

For example, if you are publishing https://www.fabrikam.com/orders and you want to protect the private information that external clients submit from disclosure to unauthorized folks on the Internet and within your organization, you can create a Web site named www.fabrikam.com on an internal server, request a certificate with the common name www.fabrikam.com from the server, install the certificate on the server, and export it to your ISA Server 2006 computer. Then, in This rule applies to this published site (the internal site name), type www.fabrikam.com, and in Computer name or IP address, type the IP address of the published server. The domain name of the published server is not used by ISA Server in this case.

If the Web site is hosted on an ISA Server 2006 Web farm, certificates with the same common name must be installed on all the farm members, and the internal site name specified on the Web Farm tab must match the common name on the certificates. To install these certificates, you can request a certificate with the same common name from each farm member. Alternatively, you can obtain and install a certificate on one farm member, and then you can export the certificate along with its private key and import it to the other farm members. In all of these cases, of course, the ISA Server computer must trust the CA that issued the certificate.

Note. If you request a server certificate on a published server and you intend to export it to a farm member or to the ISA Server computer, the certificate must have an exportable private key. When you import a certificate to a server, in the Certificate Import Wizard opened from the Certificates snap-in, you select Mark this key as exportable on the Password page.

ISA Server 2004 only supports wildcard certificates on the ISA Server computer. ISA Server 2006 also supports the use of wildcard certificates on the published Web server for publishing multiple Web sites using a single certificate. When using HTTPS to HTTPS bridging, you cannot use a wildcard certificate on an ISA Server 2004 computer to authenticate the internal Web server. Instead, on the internal Web server, install a different certificate that matches the name of the internal Web server, as specified on the To tab in the Web publishing rule.

After the SSL handshake is completed successfully and the SSL connection is established, the HTTP GET request can be forwarded to the published Web server. As in the case of forwarding an HTTP GET request without SSL that I described in Part I, if the Forward the original host header instead of the actual one option is selected, the Host header that is included in the request will contain the host name specified in the original URL requested by the client. If this option is not selected, the Host header will contain the name or network address of the published server (ISA Server 2004) or the internal site name (ISA Server 2006) that is specified in the properties of the applicable Web publishing rule.

There is one issue that should be mentioned here. In the case of HTTPS-to-HTTP bridging with the Forward the original host header instead of the actual one option selected, ISA Server 2006 adds the port number 443 to the Host header if a port number was not included in the original URL. If the Web application that is running on the Web server does not expect the Host header to include the port number, the Web application may generate an error. For information about how to resolve this issue, see the Microsoft Knowledge Base article 925287 “ISA Server 2006 includes the Host header together with the port number of the Web server after you publish a Web site.”

Pesach Shelnitz
Forefront TMG (ISA Server) Team

Published Thursday, June 19, 2008 10:28 AM by isablog

Forefront TMG (ISA Server) Product Team Blog : Another Look at Web Publishing. Part II: Host Headers with SSL and Certificates

Another Look at Web Publishing. Part I: Host Headers without SSL

The purpose of this series of blog entries is to describe some details of Web publishing with the hope that by getting back to basics and taking another look at how Web publishing works, you’ll be able to create more efficient, error-free Web publishing rules with greater ease. In this post, I’ll try to explain how Host headers are used in ISA Server Web publishing in the simple HTTP scenario without SSL, and then in Part II, I’ll try to extend the picture described here to scenarios with SSL.

URLs: The Source of the Host Name

When an external user wants to retrieve content from the Internet in a Web browser, the user must provide a URL, which identifies the resource to access. The URL can be provided in several ways, such as by typing the URL in a text box or by clicking a link containing the applicable URL. The Web browser then uses the information in the URL to connect to the Web server and send a request message to the Web site for the resource requested.

Let’s examine some details of this process. A URL can include several components, some of which are optional. For example, the URL http://www.fabrikam.com:80/products/catalog.aspx?category=shoes&model=123 includes the components listed in the following table.

 

Scheme	http
Authority	www.fabrikam.com:80
Path	products/catalog.aspx
Query	category=shoes&model=123

The first component of a URL is the scheme, which is separated from the rest of the URL by a colon followed by two slashes. The scheme determines the required syntax for the rest of the URL and indicates how it should be interpreted. In this blog entry, we will confine ourselves to the syntax for HTTP URLs, that is, the syntax of the sample URL just given.

The authority component includes the host subcomponent, which is the most important part of the URL for this discussion, because it is copied into the Host header in an HTTP request message. In this example, the authority component consists of only a host subcomponent with a host name and a port (80). In this case, the port can be omitted without altering the meaning of the URL because the default port for HTTP is 80. Note also that the query string included in the sample URL is optional and is not important for this discussion.

TCP Connections for Sending HTTP GET Requests

A Web browser, such as Internet Explorer, uses the host name in a URL both as both the name of the server with which it must establish a TCP connection in order to send request messages to the Web site and as the name of the Web site itself. Before the Web browser can establish a TCP connection with the server, it must obtain the IP address of the server, for example, by querying DNS (unless, of course, the host name is provided in the form of an IP address). The Web browser then sends a TCP SYN packet to the IP address obtained and the port specified in the URL (or to port 80, the default port for HTTP) to start the three-way handshake for establishing a TCP connection. For this process to succeed, the server must be listening on the applicable port.

If the Web site is published by ISA Server, the host name must resolve to an IP address of an ISA Server computer that is specified in the properties of a Web listener associated with a Web publishing rule (or to the IP address of a device that will direct requests to an ISA Server computer), and the TCP connection must be established with the ISA Server computer.

Note. This process may fail with the Winsock 10060 error (WSAETIMEDOUT, Connection Timed Out). This error means that there was no response to the TCP connection attempt and usually indicates some sort of network problem.

After the TCP connection is established, the Web browser sends an HTTP GET request with the information specified in the URL to the ISA Server computer. In GET requests sent directly from a Web browser to a Web server, the path is included in the first line of the request, and the host name is specified in the Host header. The request line and Host header in a GET request for our URL would appear as follows:

GET products/catalog.aspx HTTP/1.1
Host: www.fabrikam.com

Since ISA Server acts as a proxy server for Web proxy clients that send outgoing Web requests to the Internet, I should mention that when a GET request is sent to a proxy server, the request is made using the full URL in its original form, so that it can be processed by the proxy just as the original client did. A GET request sent to a proxy server for the URL http://www.fabrikam.com:8080/products/catalog.aspx would appear as follows:

GET http://www.fabrikam.com:8080/products/catalog.aspx HTTP/1.1

Notice that there is no Host header in this GET request.

When an incoming GET request for a published Web site arrives at an ISA Server computer, ISA Server determines if the Host header in the request corresponds to a public name allowed by a Web publishing rule associated with the Web listener that allowed the TCP connection. The options on the Public Name tab of each Web publishing rule specify whether the rule applies to any host name (or IP address) that may appear in the Host header of a GET request or only to the one or several host names (or IP addresses) that are listed on the Public Name tab. ISA Server forwards only GET requests with a Host header containing a public name that is accepted by an applicable Web publishing rule.

The Host header in a GET request arriving at an ISA Server computer that publishes one or more Web sites may contain one of several fully qualified domain names (FQDNs) that resolve to the same IP address. In this case, the Host header distinguishes between different FQDNs that share a single IP address and can be used to route requests to different Web sites on the same server.

From the point of view of the client Web browser, the ISA Server computer is the Web server specified in the Host header. However, from the point of view of the ISA Server computer, the published Web server is an internal server. If the request is allowed by a Web publishing rule, the ISA Server computer must still connect to the published Web server and forward the GET request to it.

In the properties of a Web publishing rule, there are options that determine the IP address with which the ISA Server computer will establish the TCP connection for forwarding a GET request to the published Web server, as well as the Host header and path that will be used in the GET request. On the To tab of a rule that publishes a single Web server or load balancer, you must provide a resolvable name of your internal Web server (ISA Server 2004) or the internal name of your Web site (ISA Server 2006).

ISA Server 2004 always uses the IP address obtained by resolving the server name specified on the To tab to establish the TCP connection for forwarding a GET request to the published server. ISA Server 2006 offers another possibility in Web publishing rules that publish a single Web server or load balancer. In the optional Computer name or IP address field, you can type a resolvable name or IP address of the published Web server. If you do, this IP address will be used to establish the TCP connection with the published Web server, and the internal name of the Web site does not need to be a resolvable name of the internal Web server. If you leave this field blank, the internal site name must be resolvable, and the IP address obtained by resolving it will be used to establish the TCP connection with the internal Web server.

After the TCP connection between the ISA Server computer and the published Web server is established, ISA Server acts as a Web client and forwards the HTTP GET request to the published Web server. By default, except in the case of certain wizard-configured rules, ISA Server changes the original Host header to a Host header that contains the name for the published Web server (ISA Server 2004) or the internal name of the Web site (ISA Server 2006). However, if the Forward the original Host header instead of the actual one option is selected on the To tab, ISA Server will establish the TCP connection with the published Web server as described, but will include the Host header received from the original client in the HTTP GET request that it sends to the published Web server.

Note. In the Web proxy log, the field for the URL requested will always contain the name of the server (ISA Server 2004) or the internal site name (ISA Server 2006) specified on the To tab regardless of how you configure the Forward the original Host header instead of the actual one option.

In ISA Server 2006, you can replace a single internal Web server by a load-balanced Web farm. When ISA Server needs to forward an HTTP GET request to a Web farm, ISA Server selects an IP address from the set of IP addresses of the farm members specified in the Web farm properties and establishes a TCP connection with the applicable farm member for forwarding the GET request to it. In this case, the internal site name and the option for forwarding the original Host header are specified on the Web Farm tab.

Note. Web publishing fails if the internal site name specified on the Web Farm tab cannot be resolved to an IP address. We recommend that you set the internal site name to the FQDN of one of the members of the server farm.

Forwarding the original Host header is useful, for example, when you want to publish multiple Web sites on the same Web server using a single Web publishing rule. In this case, the original Host header is now used only to identify the Web site on the published server, and not the published server itself.

In Part II, I’ll try to explain how the picture described here changes when one or both of the TCP connections must become an SSL connection for encrypted communication.

Pesach Shelnitz
Forefront TMG (ISA Server) Team

Published Thursday, June 19, 2008 10:09 AM by isablog

Forefront TMG (ISA Server) Product Team Blog : Another Look at Web Publishing. Part I: Host Headers without SSL

Citrix outlines desktop as a service vision

Just as the IT industry digests the impact of software as a service, Citrix touts its desktop as a service products and vision to UK customers.

By Miya Knights, 11 Jun 2008 at 11:50

Citrix has today outlined its portfolio of new and updated products for delivering applications in the cloud or through a distributed environment, including a new appliance capable of delivering the "desktop as a service" (DaaS).

Read the rest of the article at the source.

Source: Citrix outlines desktop as a service vision | IT PRO

 

ISA Server 2006 Service Pack 1: New features and enhancements

• Published: Jun 10, 2008
• Updated: Jun 10, 2008
• Section: Tutorials :: Configuration - General
• Author: Marc Grote
• Printable Version
• Adjust font size:

An overview of the new and enhanced features in ISA Server 2006 Service Pack 1.

Many ISA Server Administrators waited a long time for the publication of ISA Server 2006 Service Pack 1. At the time of writing this article, ISA Server 2006 Service Pack 1 is still not available as RTM, but as a Beta version.

ISA Server 2006 Service Pack 1 has many improvements on ISA Server 2006 and more new features than any other published Service Pack. The number of new features is so long that I personally call ISA Server 2006 Service Pack 1 – ISA Server 2006 R2.

The number of new and enhanced features might be the reason for the delay for publishing the next version of ISA Server 2006 – called Microsoft Forefront TMG (Threat Management Gateway).

ISA Server 2006 Service Pack 1 New Features

• Configuration Change Tracking

All configuration changes of the ISA Server configuration can be saved for later review. This will give administrators a better overview of what has been changed and if there are multiple administrators, who has changed the configuration. The Configuration Change Tracking feature can also be used as a Server checklist of what has changed in the ISA configuration.

• Web Publishing Rule Test Button

As most of your ISA Server Administrators know, the configuration of a secure Webserver Publishing rule with HTTPS to HTTPS or HTTP bridging could be an challenge, because many things have to be considered: you have to select correct certificates, name resolution is critical, and more. With ISA Server 2006 Service Pack 1 a new Web Publishing Rule Test Button has been integrated in ISA Server 2006 Service Pack 1 which should help you test created Webserver Publishing rules. ISA Server will then check if the Internal Server is reachable from the ISA Server side and outside the Firewall.

• Traffic Simulator

The new Traffic Simluator function in ISA Server 2006 is a great feature to simulate network traffic through ISA Server 2006. The Traffic Simulator will send simulated traffic through the ISA Server rules engine as real traffic would flow through ISA. The new Traffic Simulator could be compared with the Active Directory Group Policy feature called Group Policy results and RSOP (Resultant Sets of Policies). This new feature is wonderful for us ISA Server Administrators because it lets us quickly check if our rule sets work as expected.

• Diagnostic Logging Query

The Diagnostic Logging query is not new to ISA Server 2006 because this feature was published in ISA Server 2004 Service Pack 3 but this feature will be enhanced in ISA Server 2006 Service Pack 1. The Diagnostic Logging Query is a feature only for concrete problems related to ISA Server Firewall rules and should only be enabled for diagnostic purposes anfd after the problem has been resolved the Diagnostic logging feature should be disabled because it consumes system resources. The Diagnostic Logging query feature in ISA Server 2006 Service Pack 1 makes it easier to see only the data that is relevant to the current troubleshooting effort.

Read the rest of the article at the source:

Source: ISA Server 2006 Service Pack 1: New features and enhancements

Forefront Client Security Will Offer Broad Support for Windows Server 2008, Including Hyper-V, NAP, and Server Core

Published 10 June 08 01:29 PM | David Burt

  Today at the Tech Ed IT Professional Conference, we announced that Forefront Client Security will offer an array of support for Windows Server 2008.  The FCS agent can now provide support for Windows Server, including Server Core, and native integration for Network Access Protection.  A new NAP-FCS integration kit is now available for download here. FCS will also provide support for Hyper-V upon its release. 

• FCS Virtualization Security
  Microsoft will provide support for virtualization with the Forefront line of security products, which includes Forefront Client Security support for Hyper-V upon its release. The FCS agent will be installable on Windows Server 2008 host and virtualized operating systems to protect against malicious threats. The FCS Management Server roles can also be installed on Hyper-V virtualized machines to consolidate management server roles.
  And there's more to come. Forefront "Stirling" protection technologies will share and use security information to dynamically respond to threats across physical or virtual environments. For example, if a user's virtual machine is offline and it's brought back online, Stirling will be able to identify that it is out of compliance and automatically trigger remediation. "Stirling" is targeted for release to market in the first half of 2009.
• NAP-FCS integration Kit
  It's finally here. The NAP-FCS Integration Kit provides customers with health policy enforcement for Forefront Client Security. The kit includes a System Health Agent (SHA) and System Health Validator (SHV) which are key services used to enforce a health policy. In addition to the SHA and SHV, this free kit provides tested guidance to quickly and easily integrate NAP and FCS. The kit will help strengthen defenses against malware by providing a means to enforce a health policy that requires FCS to be installed, functioning, and up-to-date. If this health standard is not met, NAP can deny access to network resources until FCS is updated, remediation occurs, and the client is returned to a healthy state. Get it here now!
• Windows Server Support
  Starting now, Forefront Client Security Agent as well as the Forefront Client Security Management Console will both support Windows Server 2008. The FCS agent also protects Windows Server Core, as well as supporting Microsoft Cluster Services. Customers can install the FCS agent to protect operating systems that are running Microsoft Clusters Services.

Want more detail?  Visit the Forefront Client Security Blog

Filed under: Forefront Client Security

Forefront Team Blog : Forefront Client Security Will Offer Broad Support for Windows Server 2008, Including Hyper-V, NAP, and Server Core

Startup Neocleus Sees Desktop Hypervisors As Key

Posted by Charles Babcock, Jun 6, 2008 03:30 PM

Desktop virtualization has its dominant vendors, namely VMware and Citrix Systems. But in an embryonic field, consider the alternatives. I'd like to cite Neocleus, an Israeli firm, which is focused on running the virtual machine at the desktop, not on a central server, under a desktop hypervisor.

Desktop virtualization from the major vendors arrives with the ability to scale to thousands of users. That's because they realize a key piece of access management needs to be built into the process, a connection broker that takes an incoming request, identifies the requestor through Active Directory, and then makes the connection to the provisioning server. They can handle hundreds or thousands of users seeking to activate their virtual machines at the same time.

But what if you only want to virtualize a handful of users at a time? Or what if you want to virtualize hundreds of users, but those users are scattered in small pockets around the company? In that case, you don't want a connection broker so much as a distributed method of provisioning the occasional end user.

When it comes to desktop virtualization, it's not yet clear what constitutes the best division of responsibility between central server and virtualized end user.

Consider Neocleus. Last week I talked to CEO Ariel Gorfung, and he emphasized the advantage of distributed execution of virtual machines on the user's existing hardware. The Xen-based, end user Neocleus VM is generated on a central server but runs on the user's machine. Because the user's environment becomes a virtual machine, it can be encrypted and locked down.

This sounds like Phoenix Technologies' HyperCore, also based on Xen, or VMware's ACE, says Rachel Chalmers, virtualization analyst at The 451 Group, and she's right. The virtual machine is running on the user's hardware, and it's got the security barriers that virtual machines can provide, but ACEs are still tied to a central ACE Management Server.

Gorfung claims Neocleus has modified Xen so that it is a client hypervisor. Hypervisors thus far have resided on servers, hosting one or more virtual machines above them and dispensing with the host server's operating system.

Gorfung says Neocleus is less like a user's virtual machine, still tethered to a central server and more like a user hypervisor, running "side by side" with the virtualized operating system and applications. The user gets the standard desktop but also has the option of "creating an extra partition in which you watch DVDs without booting all of Windows," says Chalmers.

Gorfung says Neocleus is trying to create a desktop hypervisor framework as open source code, and any vendor should be able to create a software appliance -- an application and operating system that's been combined into a virtualized file set -- and plug it into the framework. Under such a scheme, the whole operating system debate between Mac OSX, Windows, and Linux goes away. Each is reduced to a virtual machine running under a desktop hypervisor and a broader world of applications opens up to PC users.

It's a great vision, but we're not there yet. It remains for Neocleus or Neocleus partners to demonstrate the power of a type 1, desktop hypervisor -- that is, one that acts as a direct, intermediary between hardware and virtual machine, not an emulation of the hardware in software above the bare metal.

Both user security and application performance could benefit from this approach. Addressing scalability, the way Citrix and VMware already have, can come later.

Startup Neocleus Sees Desktop Hypervisors As Key - Virtualization Blog - InformationWeek

Sunday, June 08, 2008 5:25 PM yuridio

TMG New Features - Policy Enforcement

1. Introduction

Throughout the years ISA Server suffered many improvements in the way that handles firewall policy, if you remember, on ISA Serve 2000 we have to stop the service so the policy could take effect immediately, which improved a lot on ISA Server 2004. However even with ISA Server 2006 there is still a common complaint from customers, which was: I applied a new ISA Server policy but I see that my user still accessing the web site. He has to close it and open a new connection in order to take effect. The answer up to now was: well, that’s expected in ISA Server. The connection that is already established will not be affect, only the new one. In TMG we have a new feature called Policy Enforcement that can address this need and this post will give you an overview on that.

2. Compliance Enforcement

The key feature of TMG in this area is the fact that it enforces the new policy for compliance purpose. In other words: if the company security policy changes and those changes need to rapidly reflect in the edge then you can just make the changes and re-apply to the TMG Server. In summary, the process works like this:

Figure 1 – Policy Enforcement.

The re-evaluation of the existing HTTP session happens right after the policy takes effect for the first traffic within the session. Therefore you could potentially see an open session for the site that you just prohibited because no traffic was exchange within that session yet.

On step two, when the administrator applies the change, the Saving Configuration Change window shows the following warning about this new feature:

Figure 2 – New configuration change window.

3. Conclusion

This is just one more improvement that you will see in TMG and it is an improvement that bring more control and security enforcement to the network administrator. For more information about policy enforcement review the official TMG documentation at TMG TechNet Library Page.

Filed under: TMG

Yuri Diogenes's Blog : TMG New Features - Policy Enforcement

rPath Enables Virtualization and Cloud Computing for U.S. Department of Energy and CERN

rPath®, whose unique technology simplifies application distribution and management through virtual appliances, today announced that the U.S. Department of Energy (DOE) and the European Organization for Nuclear Research (CERN) have been using rBuilder® to deliver virtual appliances to both scientists’ desktops and computational clouds. The use of rBuilder in these environments reduces the effort required to support users and allows researchers to take advantage of underutilized computational resources.

rBuilder is the first and only product that simplifies and automates the creation of virtual appliances. A virtual appliance is an application with a streamlined operating system, offered in a format that runs in virtualized environments.

CERN turned to virtual appliances to facilitate the analysis of data created by the Large Hadron Collider (LHC) experiments. The complete software environment needed by the LHC applications is assembled by rBuilder and distributed to run as a virtual machine on physicists’ desktops. Virtual appliances provide a consistent application environment for the LHC applications while, at the same time, allowing scientists to use their desktops for analysis, regardless of operating system.

Read the complete article at the source.

Source: rPath Enables Virtualization and Cloud Computing for U.S. Department of Energy and CERN : VMblog.com - Virtualization Technology News and Information for Everyone

Feed: Planet V12n
Posted on: Tuesday, June 03, 2008 11:28 AM
Author: Planet V12n
Subject: Hyper-V could benefit from VMware’s Xen-based competition (Server Virtualization Blog)

If Hyper-V doesn’t convert the VMware faithful as soon as Microsoft makes its hypervisor generally available later this year, it may get a little help from its friends: Xen-based virtualization platforms.

Some like IT consultant Ardalan Dlawar believe that Microsoft will leverage support for Xen-based platforms to increase competition with VMware. “And Xen will have more third-party support and fewer compatibility issues,” according to Dlawar.

Despite user arguments that ;Hyper-V will have to deliver more than a lower price tag to win users, Hyper-V will certainly get consideration from many VMware customers. While organizations want to maximize their VMware investment, especially enterprise customers which deploy tens or hundreds of VMware virtual machines, Hyper-V evals will most likely be deployed, according to Andi Mann, the research director at Boulder, Colo.-based Enterprise Management Associates (EMA).

Based on a survey of more than 600 enterprises, EMA found about 30% of enterprises have already planned a Hyper-V deployment even with Hyper-V’s general availability several months away. In addition, Microsoft is actually within 10% of VMware in current and planned enterprise deployments according to EMA’s data. Also consider this EMA finding: Xen-based platforms already account for more than 40% of current or planned deployments, the data suggests that the market demand for VMware alternatives won’t disappear.

“VMware is still way out in front in server virtualization,” said Mann, “but both Microsoft and Citrix Systems are definitely catching up.”

Of course, VMware and Microsoft aren’t the only options available. As managers continue utilizing toolsets available from Xen-based products such as Citrix’s XenServer and Virtual Iron Software, VMware and Microsoft are both working on tool sets that enable users manage their virtualization counterparts respectively.

“Both VMware and Microsoft understand that they are not going to be the only players on the market, they recognize that customers are leveraging their competitors’ technology in different parts of their businesses,” according to Adnan Hindi, the VP of operations at ScienceLogic in Reston, Va. Hindi said that companies like his, which produces cross-platform appliances, will benefit from multiple-platform virtual landscapes. As shops continue to see benefit in the utilities that Xen-based products offer, Hindi sees a universal virtualization tool set ultimately working itself out; these tools would essentially equalize platforms in the market and dilute decision making in choosing a virtualization platform largely down to cost.

Over the past year, there’s been a lot of talk about VMware’s cost of VMware. But the price of VMware Server is right for small businesses, said Brett Riale, an IT consultant in Pittsburgh, who feels “truly blessed that programs as functional as VMware Server have been released for free.” Riale is hesitant to trust another Microsoft virtualization product after “the debacle” that was Virtual Server 2005. “Unless it absolutely outperforms VMware,” Riale said that he won’t consider Hyper-V in the near future. And Dave Baughman, a systems administrator for Muncie, Ind.-based Ontario Systems, thinks that his ESX system is “a consistent platform” and that the price of support is worth their investment. “Most of the cost is for support and (VMware’s) support is very good,” says Baugham.

But what will happen when all the Microsoft customers with enterprise agreements get a taste of Hyper-V support? Or if Microsoft offers more third-party support for Xen?

Howard Holton, a system engineer, said that market share will shift in Hyper-V’s favor.

“Hyper-V is an excellent solution for many of those that cannot afford the steep cost that ESX server requires,” says Holton, who has already has a positive experience working with the release candidate and points out that for most data center operations, VMotion’s High Availability (HA) is overkill. ”Hyper-V fits into the market below VMware for hosts that do not need true HA.”

Holton said that in the long run Hyper-V might win out over VMware because Citrix’s XenServer has finally given Xen a roadmap. XenServer is the spoiler, with a lower TCO than VMware. Although price hasn’t deterred Holton from delivering VMware to his customers in the past, he predicted that Hyper-V will only increase in value.

“As a value-added reseller in the small to midsized space, VMware is the leading virtualization product that I offer. That is changing.”

View article...