Microsoft Forefront Unified Access Gateway Product Team Blog : IAG SP2

Publishing CRM Outlook Client Using IAG SP2

edgeaccessblog — Mon, 09 Mar 2009 10:28:00 GMT

IAG SP2 introduced support for Dynamics CRM 4.0 Web application. This support enables IAG SP2 to protect and enhance the CRM servers – look here for more details. This support can be extended to the CRM Outlook client using the steps detailed below.

I. Adding the application on IAG

1. In a portal trunk, select to add a new application.

2. Select "Generic Client App" as the application type from the "Client/Server and Legacy Applications" combo-box:

3. Type a name to identify the application:

4. Fill in the server address and port, and make sure that the "Launch Automatically on start" option is checked:

5. In the “Portal Link” page, make sure that the "Add link on portal and toolbar" is unchecked and then click Finish

6. From the trunk’s application list, open the application that you just created. Go to the "Client Settings" tab and check the "Extended" option:

II. Configuring the CRM Outlook Add-on Configuration Manager

Prerequisites: The initial configuration of the add-on should be done from a domain-joined machine.

1. Run the CRM Add-on configuration manager and choose "My Company":

2. In the "Intranet Address" fill in the CRM server's name, uncheck the "Use the same Web address" checkbox, and in "External web address" fill in the IAG portal address followed with a "/MSCRMServices" path.

Start working…

Now IAG users can use their CRM Outlook client. All they have to do is log in to the IAG portal. After login they will be able to use their CRM Outlook client for as long as their IAG session is valid.

Author: Chen Kirsch, IAG Product Team Application Group

Reviewer: Meir Mendelovich, Program Manager, IAG Product Team

After installing IAG 2007 SP2 - Mobile Devices can no longer synchronize through IAG

edgeaccessblog — Thu, 15 Jan 2009 19:57:00 GMT

With the release of IAG 2007 SP2 (although this behavior can happen with any new update), we have been receiving some support calls about this subject and we want to bring some awareness about this behavior. Last year we published two posts about Active Sync configuration on IAG 2007:

http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

http://blogs.technet.com/edgeaccessblog/archive/2008/07/29/publishing-microsoft-activesync-through-iag-2007-part-2-of-2.aspx

When you use Part 1 of this article you will notice that step 9 advises to make a modification to the file \Whale-Com\e-Gap\von\InternalSite\ActiveSyncLogin.asp in order to enter the authentication repository. This works, but there is a caveat that wasn’t mentioned in the original post. The caveat is that changes made to IAG’s default ASP/INC/etc. files could be overwritten when software updates are applied to IAG. So the question now is: what should I do?

There are some others approaches to achieve this task and here are the options that you have:

Method A) Add a custom “.inc” file in the CustomUpdate Folder

· How:

1. Create a file named [TrunkName](0|1)ActiveSyncLoginStart.inc in ..\Whale-Com\e-Gap\von\InternalSite\inc\CustomUpdate\

2. Within this file add the following content:

<% 'This file defines the repository that is used for ActiveSync for this trunk.

repository = “[RepositoryName]”

· Pros: easy to customize, flexible and update independent, will be backed up with an IAG backup.

· Cons: in comparison to the other methods, this requires an .inc file to be created for each trunk that runs ActiveSync and the file name needs to match the trunk name.

Method B) Create an ActiveSync specific repository that matches the domain name.

· Pros: Works out of the box. There will be no need to edit or maintain custom files and it will be backed up with an IAG backup.

· Cons: creates limitation in naming convention of repository.

Method C) Create a CustomUpdate ActiveSyncLogin.asp

· How:

1. Copy ActiveSyncLogin.asp from ..\Whale-Com\e-Gap\von\InternalSite to ..\Whale-Com\e-Gap\von\InternalSite\CustomUpdate

2. Modify the version in the CustomUpdate directory

3. Open the Advanced Configuration for the ActiveSync trunk

4. Select the Authentication Tab

5. Change the Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

6. Change the On-the-Fly Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

· Pros: Very advanced option that is not recommended unless major parts of ActiveSyncLogin.asp are to be re-written and designed to persist on software updates, will be backed up an the IAG backup

· Cons: Updates to IAG that change ActiveSyncLogin.asp will not be applied to the custom file any changes to the default file will have to be monitored and merged into the custom file manually after every update.

Now you just need to plan which option best fits with your needs and start deploying it.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Tech Reviewers

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

Ophir Polotsky

Forefront Edge Supportability Program Manager

Microsoft – Israel

John Redding

Security Support Engineer – IAG Team

Microsoft - Washington

Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 2

edgeaccessblog — Thu, 08 Jan 2009 18:47:00 GMT

Here is the second part (first part is here) of how to secure access to your data center with IAG.

Implementing Data Center access with IAG

Which applications?

As a first stage, I would suggest that you route Web applications through IAG. This is where the user experience will be optimal and most protection will be provided. To do this you will need to publish these applications using the IAG Configuration console, and specify the security policies that will control access to these applications.

You don’t have to publish all Web applications at once through IAG. You can do this incrementally, starting with high business impact applications for which security is a high priority. Let other Web application and non-web traffic continue to flow directly to the application or Web server. Securing non-Web traffic requires additional considerations. The performance overhead will usually be significant, and pre-authentication of non-Web traffic requires IPSec deployment, which is fairly complex. You can read about deploying IPSec for deploying Server and Domain isolation at http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/.

Making clients to go through IAG instead of directly reaching applications

So how do you make clients access the applications through IAG instead of accessing them directly? There are two potential strategies you can employ:

1. If your clients access Web applications through an enterprise portal, modify portal links to the applications to point to IAG.

2. Modify your DNS infrastructure to make clients go to IAG.

Allocate two DNS names to each Web application – one internal and one public.

Change the hostname of the application to be internal DNS name, and configure this internal name on the IAG settings for the published application. For example change http://crm è http://crm-internal and http://app1 to http://app1-internal .

Now there are two ways to make public names to point to IAG –

a. Add the public DNS name (e.g. http://crm and http://app1) as an additional host name for the IAG trunk and point to the IAG IP address. This is the DNS name that users will use for quick access to the application through IAG. You will also need to include all public DNS application names on the SSL certificate used for trunk configuration, or use a wildcard certificate. This is shown in orange color on the diagram below.

b. You can use a simple single name certificate with IAG’s portal name only (e.g. http://portal) by setting up a simple Web server to act as a “redirector”. To do this register all public DNS names (e.g. http://crm and http://app1) to resolve to the redirector IP and configure it to redirect all requests to IAG portal (http://portal). This is shown in blue color in the diagram below.

IAG portal

An IAG portal organizes all applications a user is authorized to access, and helps users to discover published applications without memorizing all the links or creating individual bookmarks.

When you deploy IAG in a data center, all your local users can benefit from IAG. If your organization already has a central portal with all corporate applications, you can choose to configure it as the initial IAG application, instead of using the built-in IAG portal. If you choose this option, you can still embed the IAG built-in portal application list as a Web part inside your enterprise portal. See “How to integrate the IAG portal into SharePoint” on how to do this.

IAG and NAP

If you have deployed NAP in your environment, then how do you deploy IAG with a Data Center alongside NAP?

Firstly you need to configure DHCP in order to assign clients that do not comply with NAP policy an IP address in a remediation network. You will then need to expose IAG to the remediation subnet, so that clients located there can access it.

In this scenario, you want IAG to perform endpoint security validation of unmanaged clients, but skip this check for managed computers, as NAP will perform this function for them. This can be achieved by configuring different policies for session access and privileged endpoint policies in the Endpoint Policies section of the trunk properties.

Assign managed clients as privileged endpoints. Do not require any endpoint settings, except for some specific file, folder, registry key or machine certificate that is provisioned on all you corporate desktops, and which is used to distinguish them from unmanaged computers.

Authentication and Single-Sign-On

A design choice that you need to make is whether to authenticate the users on IAG. Pre-authenticating users on IAG prevents any unauthorized traffic from ever reaching application servers. This is an important security function during remote access. As you would like to keep user experience simpler during access of applications from local network, it is desirable that they will not need to type credentials during the access, similar how they access the applications without IAG.

There are two ways to achieve this:

Use seamless authentication, when a browser is transparently authentications with IAG, without requiring user to enter credentials explicitly. Rest of this section will focus on how to achieve this with IAG with Integrated Windows Authentication (IWA) or Active Directory Authentication Services (ADFS) and Kerberos Constrained Delegation (KCD).
Require no authentication on IAG, so that IAG only enforces client health, but doesn’t pre-authenticate the users. This reduces the security IAG provides, but is usable in many scenarios.

Integrated Windows authentication

The first step is configuring front-end authentication – how users are authenticated by IAG. When you want to publish applications to your internal Active Directory users, the best choice would be Integrated Windows authentication, which uses Kerberos and NTLM protocols. When IWA is used, all users from IAG Active Directory forest and any trusted Active Directory forest will be able to login to IAG without re-typing their credentials. There are few things to be remembered before you configure IWA:

· IAG server should be a member server of your Active Directory forest. If you plan also to use KCD to provide SSO to backend applications, IAG server and application server must be members of the same domain.

· If you plan to use Kerberos as part of IWA, all public trunk names must be registered as SPN of IAG server. That includes published SharePoint servers’ external names. For instance if you have a trunk with a public name www.contoso.com and you IAG server is called my-iag-server, then you must access AD account of my-iag-server and add “http/www.contoso.com” as it’s SPN.

For more details about how to plan and configure IAG to use Integrated Windows authentication you can read “About publishing applications to users located on corporate networks with IAG SP2” and “Publishing applications to users located on corporate networks with IAG SP2”

Active Directory Federation Services

While Integrated Windows Authentication is mostly suited for internal users, the solution for your extranet users is to implement ADFS authentication on IAG. You can also use ADFS when establishing two-way trust between users and IAG domain is not possible.

IAG support ADFS v1 NT-tokens mode. There are several prerequisites to remember when you plan to use ADFS authentication on IAG.

· IAG server should be domain member of Active Directory forest, where your applications (resources) are located.

· NT-tokens mode requires shadow accounts configured in resource Active Directory forest. IAG supports user-to-user and group-to-user mappings between users’ forest and resource forests.

· IAG requires that Federation Server Proxy (FS-P) will be implemented on IAG server.

For more information on implementing ADFS on IAG see - Enabling Active Directory Federation Services in IAG SP1.

If your application supports ADFS authentication, you can allow users to directly authenticate to the application using ADFS, just don’t enable authentication delegation on IAG.

If your application doesn’t support ADFS, you can use Kerberos constrained delegation, described later on, to provide Single Sign-On experience to your partners’ users. By implementing ADFS on IAG, you can provide ADFS login to applications that are not extranet ready.

Authentication delegation and Single Sign-On

The next step is to plan how users will authenticate to the applications. There are several options for you to choose, each of them have different user experience, prerequisites, pros, and cons.

Kerberos constrained delegation provides full Single Sign-On user experience and users are not required to re-type their credentials. When KCD is performed, IAG performs Kerberos authentication to the application on behalf of the user. There are several things to be remembered before enabling KCD on IAG server.

· The very trivial, but most forgotten one – application must support Kerberos authentication. Sometimes, when application states it supports Windows login, it really supports only the NTLM. A great tool to verify which authentication is supported by your web application is Wfetch.

· If your application is servers farm that uses Load Balancer or Application Delivery Controller to distribute requests between servers, you’ll have to run all instances of your application on all servers under same security identity. Otherwise Kerberos authentication will not work. This means that instead of running your application pool with “Local System” identity, you’ll have to create application user, register your application SPN for that user and reconfigure all your servers to run application with this user identity. For more information on how to configure Kerberos authentication in IIS 6.0 please read Integrated Windows Authentication (IIS 6.0).

· IAG server and application server must be members of the same Active Directory domain.

· When your users reside in separate Active Directory forest, there should be two-way trust between users Active Directory forest and application Active Directory forest.

· KCD requires Active Directory configuration changes each time you publish a new application that uses KCD. Don’t worry, IAG will help you to make the change easy and will create an LDIF script file that can be imported to your Active Directory, but you’ll need a help from someone with Active Directory administrative rights to actually import it.

All the details are available in “Configuring Kerberos constrained delegation with IAG SP2”

When implementing KCD is impossible you might want to consider implementing authentication pass-through. Since both the user and the application belong to either same or trusted Active Directory forests, we can assume that user can seamlessly login to the application directly using Integrated Windows authentication. The idea of authentication pass-through is to allow the user to authenticate directly to the application, once user authenticated to the IAG. This is possible with the NTLM protocol. So when you decide to use authentication pass-through, you’ll have to disable Kerberos in IAG trunk configuration, disable authentication delegation handling and enable authentication pass-through on IAG server.

When neither of the above options is possible to implement, you can still configure IAG authentication delegation. User will be prompted for credentials when accessing the application, but only once through the session and these credentials can be reused to all applications that share same authentication server. For instance when you publish number of SharePoint servers that use same Active Directory, user will be prompted for credentials only when accessing first SharePoint server; when subsequently accessing other SharePoint servers, IAG will reuse provided credentials on behalf of the user and provide Single Sign-On experience.

Virtualized Data Centers

Many customers are planning and deploying virtualized data centers today. If you are one of those, you can deploy IAG as a virtual machine using the pre-configured IAG SP2 VHD. See my previous blog post at http://blogs.technet.com/edgeaccessblog/archive/2008/11/26/iag-sp2-goes-virtual.aspx for more details.

Authors

John Neystadt, Architect

Eli Tovbeyn, Sr. Program Manager

Technical Reviewers

Meir Mendelovich, Sr. Program Manager

Ran Dolev, Sr. Support Engineer

Noam Ben-Yochanan, Sr. Program Manager

Oleg Ananiev, Group Program Manager

Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 1

edgeaccessblog — Tue, 23 Dec 2008 17:46:00 GMT

John Neystadt is here again. Today I am blogging first part of an overview of how to protect Data Center applications with IAG. Hope you are enjoying the holidays. I will blog second part after they are over.

Changing threats blur the difference between remote and local access

For many years network and security departments engineered their networks around the concept of physical security. Establish a security perimeter; guard physical access to a building with human guards and badges; guard network perimeters with an access gateway using strong user authentication; verify endpoint compliance with a security policy that enables restricted access to corporate applications, knowing that when users connect remotely threats are greater than when they connect locally.

However, mobility and increased outsourcing have changed the threat landscape for local access. There are a number of questions that many security departments ask themselves today:

· How do I know who connects to my Wi-Fi network from the parking lot or lobby?

· How do I control which applications can be accessed from mobile phones?

· Do I trust on-site vendors to the same degree as employees?

· How do I mitigate the risk from guests’ unmanaged laptops that are allowed to access my business applications?

· How do I enable and secure access to my data center for clients that are not controlled by my IT department. For example:

o My company has recently merged with or acquired a company that uses a different desktop security standard.

o My company has outsourced desktop management and I can’t control what is installed on desktops.

o My IT environment is loosely coupled as is my organization (this is common for government, educational, and many other organizations). I am in control of the data center only, but not of the clients.

· How do I enforce compliance for all above scenarios, and be able to monitor and audit all these activities?

If you are asking yourself one or more of these questions, than perhaps you are ready for reperimeterization - and IAG 2007 SP2 can help you.

Reperimeterization and the changing role of perimeter security

The idea behind reperimeterization (also known as deperimeterization) is simple. Let’s separate data centers and clients, and route all access to corporate applications through a data center gateway which provides the same level of security as that which we enforce for remote access.

What am I gaining from such a configuration?

1. I can provides users coming from different domains or partners with a great seamless single sign-on experience, without requiring them to explicitly enter credentials when accessing Web applications. This can be done using a combination of either Integrated Windows Authentication (IWA) or Active Directory Federation Services (ADFS), and Kerberos Constrained Delegation (KCD) authentication delegation.

2. I can implement granular access control, based on the endpoint security state of the client (For example, is the endpoint patched? Is it running an antivirus with recent signatures? Is an anti-malware application turned on?). You might ask what the difference is between IAG and NAP endpoint policies. NAP is a great and simple way to enforce and automatically remediate endpoint compliance for environments that have standardized on a single desktop standard, as NAP expects a specific anti-virus or anti-malware to be present. NAP is binary about client compliance. If a client doesn’t comply with NAP, then the client is restricted to the remediation network. You certainly should use NAP for managed client computers. However, when dealing with loosely coupled environments or “unmanaged” computers - when you don’t control the clients and can’t enforce a uniform standard - you need a technology that enables “unmanaged” Windows, Linux and Mac clients to access a restricted set of applications while enforcing policies such as “must have any anti-virus” or “must have any anti-malware software installed”. In addition NAP supports Windows XP SP3 and newer client operating systems, and you can NAP for these client endpoints, in combination with IAG endpoint security to secure Windows 2000 and pre-Windows XP SP3 clients.

3. I can monitor and log all application access using the IAG Web Monitor.

Authors

John Neystadt, Architect

Eli Tovbeyn, Sr. Program Manager

Technical Reviewers

Meir Mendelovich, Sr. Program Manager

Ran Dolev, Sr. Support Engineer

Noam Ben-Yochanan, Sr. Program Manager

Oleg Ananiev, Group Program Manager

Intelligent Application Gateway 2007 Service Pack 2 is now available!

edgeaccessblog — Fri, 19 Dec 2008 14:56:00 GMT

We are happy to announce the availability of IAG SP2.

Marking a significant milestone for our product, Service Pack 2 brings with it a variety of enhancements that improve overall IAG scalability, interoperability, and functionality. Alongside these benefits, IAG SP2 has the ability to run as a virtual machine on Hyper-V, achieving low TCO, deployment flexibility, and a simplified solution for disaster recovery. For the first time ever, customers are able to download a fully functional, trial version of the IAG that can be used in their production environment.

· For more details look at our product page: http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/

· Or just downlod SP2: http://www.microsoft.com/downloads/details.aspx?FamilyID=e69dfd1d-d333-4c27-9246-279ada224317

· Video interview on SP2 with out esteemed Product Manager, Uri Lichtenfeld : http://edge.technet.com/Media/IAG-SP2-hits-RTM-details-under-the-cover-interview/

· SP2 Release notes and dedicated documentation: http://technet.microsoft.com/en-us/library/dd282918.aspx

· We also hope that our SP2 related blog post will be helpful (more to come): http://blogs.technet.com/edgeaccessblog/archive/tags/IAG+SP2/

IAG product team wish you and your family happy holidays

(we are sure that you will use all this free time to install and evaluate SP2 J)

IAG product team celebrates SP2 release

IAG SP2 Goes Virtual

edgeaccessblog — Wed, 26 Nov 2008 12:54:00 GMT

My name is John Neystadt and I am an Architect with the Intelligent Application Gateway (IAG) product team.

Why have customers come to love hardware-based appliances?

1. Appliances are very easy to deploy –plug in a few network cables, turn on, go through an initial wizard and you’re ready!

2. Appliances are secure – typically pre-hardened and pre-configured to serve a single purpose.

3. Appliances are easy to manage – they are intended for a single purpose, which means fewer configuration errors or unexpected impact from software that doesn't serve the core appliance purpose.

4. Appliances are easy to troubleshoot and support – vendors provide one-stop support for both hardware and software problems.

However with the great strides that virtualization technology has made in the last few years, we now have the ability to bring together the appliance experience with the benefits of virtualization.

To address these issues, we have come up with a solution that combines the best of all worlds – you can either deploy Intelligent Application Gateway as a hardware appliance from one of our experienced OEM partners, OR you can deploy IAG with SP2 as a virtual machine on a server running Windows Server 2008 with the Hyper-V role enabled or on Microsoft Hyper-V Server 2008, Microsoft’s optimized, hypervisor-based virtualization solution.

So what’s new with SP2? First off, the ability to get IAG as a pre-configured virtual machine. In addition, IAG now has a Getting Started Wizard that guides you through all the initial setup steps when booted for the first time. Deploying IAG with SP2 as a virtual machine has many of the combined benefits of software products, virtualization, and hardware appliances:

1. It is pre-configured, so it is very easy to get deploy and get started.

2. It is hardened and secured.

3. It has a single purpose, so it is easy to manage.

4. You can run it on any industry standard server that supports virtualization - and install either the Windows Server 2008 Hyper-V role or Microsoft Hyper-V Server 2008.

5. You can create a dedicated test system and move IAG virtual machines between the test system and the production system, by simply copying an image file.

6. Backup and restore is simple – just periodically copy the virtual machine image from the production system to another location.

7. Disaster recovery is easy – just configure a new server and copy the virtual machine images to it.

8. Server consolidation - If IAG doesn’t utilize your entire server (CPU, Memory, I/O), you can run additional virtual workloads, such as load balancing software, on the same physical server.

SP2 introduces a number of additional features in addition to the ability to being deployed as a pre-configured virtual machine.. Features include interoperability for non-Windows environments with support for Firefox, Linux and Mac, new, optimized, application support for Microsoft Dynamics CRM Web and OCS Web client. There is also support for Windows Integrated Authentication and improvements in Kerberos Constraint Delegation Authentication, simplifying user and administrator experience in data center deployments (these features will be the subject of separate blog posts in the coming weeks).

IAG SP2 will be released in the next few weeks. Please register for TechNet Newsflash to be the first to download the trial bits!

Securely Publishing Dynamics CRM 4.0 by Using IAG SP2

edgeaccessblog — Fri, 07 Nov 2008 01:10:00 GMT

[Cross post with Microsoft Dynamics CRM team blog]

We are pleased to announce the upcoming availability of Microsoft Intelligent Application Gateway (IAG) Service Pack 2 (SP2), which provides a number of key enhancements, including a new application optimizer for Microsoft Dynamics CRM 4.0. The IAG team has always viewed CRM implementations as an important scenario, and we feel confident that this update will help you protect your CRM deployments.

Most organizations want to make their CRM application available to remote employees and business partners, but the application often also contains extremely sensitive information. These scenarios require special attention to the related security issues, including providing a means of protecting the CRM server and preventing unattended information leakage. IAG SP2 provides built-in support for all of these requirements – specifically adapted for Dynamics CRM 4.0, and with a very quick and easy administrator experience.

Using the new SP2 application optimizer to publish a Dynamics CRM 4.0 deployment automatically:

· Prevents file downloads from unhealthy or unmanaged computers

· Prevents uploads for computers that aren't running an anti-virus program

· Controls who can export CRM data to Excel, and from which devices

· Cleans the user’s cache and temporary files after a session ends (e.g. if your CEO used “export to Excel” from an Internet kiosk…)

· Adds timeout and logoff functionality to reduce the risk of session hijacking

· Provides strong authentication to CRM servers (for example, smartcards and one-time passwords)

· Supports ADFS

· Provides single sign on (SSO) to and from the CRM server to any other application published by IAG

· Forwards only valid HTTP requests to backend servers

Note: Also keep in mind that because the CRM server is separated at the application level from external users, it is already protected from most malicious attacks.

As always, the IAG team performed extensive testing on Dynamics CRM 4.0 behind IAG to ensure that SP2 doesn't break any CRM functionality or harm performance.

Making it easier to provide Internet access to an organization’s CRM application can unlock new and exciting models that leverage the current CRM deployments:

· Allow secured access from unmanaged computers and devices - such as employees’ home computers, Internet kiosks, and mobile devices.

· Provide business partners with access to a subset of CRM functionality to allow them to update their work without employee involvement. IAG SP2 handles the authentication (e.g. using ADFS) and ensures that partners cannot access sensitive data or parts of the system, or perform actions such as exporting data to Excel.

For example if a subcontractor is providing service for all your customers in a specific region you could allow its employees to access contacts and service for their customers but block them from viewing contracts, quotes, marketing or upload files.

For more information, see http://www.microsoft.com/iag. Additional detail will also be provided later this month at the Convergence EMEA conference in Copenhagen.

Jim Toland, MS Dynamics CRM Engineering for Enterprise team

Meir Mendelovich, IAG Product Group

IAG SP2 – It is all about the application

edgeaccessblog — Sun, 02 Nov 2008 17:12:00 GMT

When Microsoft acquired Whale Communications about 2 years ago, there was a big question of how will Microsoft change the future of the access industry. As remote access was mainly a networking solution delivered by the networking vendors, the entrance of Microsoft into this game was sure to change the perception and the rules of this industry.

Today, I would like to call out your attention to a new Service Pack 2, which will be announced this week at Tech-Ed EMEA (Barcelona, Nov 3-7). In releasing IAG Service Pack 2, Microsoft is making the first step in a multi-year roadmap to deliver on the promise of seamless anywhere access, transforming it into a trivial task for any user, anytime and anywhere.

IAG SP2 centers around three core themes: virtualization, interoperability and application intelligence.

Virtualization:

Adding to the existing physical appliance offerings by our OEM partners, IAG SP2 will introduce the option of running as a virtual machine on Hyper-V Server 2008 or Windows Server 2008 with Hyper-V. This option enables customers to deploy the IAG solution in a flexible, secure, and low-TCO manner - important benefits as organizations seek more and more ways to cut costs. It opens new horizons for IAG in the modern corporate environment.

Interoperability:

With productivity as a main goal, and the ability to access from anywhere one of its core staples, IAG needs to extend beyond the managed- and Microsoft-oriented environments of Windows and Internet Explorer. Therefore, IAG SP2 introduces enhanced support for non-Microsoft environments such as Linux, Mac and Firefox.

Application Intelligence:

IAG SP2 continues to deliver on the promise of granular application control. It incorporates the previously released SharePoint alternate access mapping (AAM) publishing, and adds support for several applications, most notably Dynamics CRM Web access and Office Communicator Web Access.

I am very excited about the coming release. This is a major step for IAG in re-defining the remote access market. Watch this space… In the next few weeks, as we near the release of IAG SP2, we will add posts that highlight some of the individual solutions and improvements.

Several members of the senior staff will also be present in Tech-Ed Barcelona this week to give a few sessions, demos, and of course to meet many of you in the community. We hope to see you there.

Assaf Ronen

IAG/UAG Product Unit Manager