Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

OWA Over a Netlet With a DNS Twist Recipe

This tasty treat is compliments of Thor Mitchell.



  • Internet Explorer 5.5SP2 with December 2002 Security update

  • One Netlet rule required to listen to HTTP traffic on port 80


  • OWA access without the rewriter rules or client-side configuration


  • Requires a split DNS configuration.

  • Embedded URLs which do not have external DNS entries will not be accessible.

  • A Netlet rule could conflict with a local web server such as IIS, personal web server, Netscape Fastrack, and so forth, using a standard port.

  • Generates significant overhead on the Gateway due to mass encryption and decryption.

  • No BASIC authentication SSO to the Exchange server.

  • Sun ONE Portal Server 3.0 software does not currently support modern browsers for the NetApps.

  • Netlet traffic may be denied by some proxying firewalls or proxies which perform SSL packet-level investigation.


  1. Create a Netlet rule to listen to local port 80.

  2. Create a public DNS entry for the Exchange server, which maps to the local loopback address.

  3. Create a link which will not be rewritten on the portal desktop, to launch OWA.


To Create a Netlet Rule to Listen on Local Port 80:

  1. Log in to the Portal Administration Console.

  2. Select Manage Domains.

  3. From the list, select the Domain name for which the Exchange users are mapped.

  4. Expand the Applications key.

  5. Select Netlet.

  6. Add OWA|null|false|80|exchange-server|80 in the form field under the Netlet Rules attribute (where exchange-server is the fully qualified address of the Exchange server).

  7. Select Add.

  8. Uncheck Warning for Popup windows.

  9. Scroll to the bottom of the page and check Apply changes to all subRoles.

  10. Select Submit.

  11. Log out of the Portal Administration Console.

  12. Log in as a user to the Portal Gateway.

  13. Verify the static Netlet rule is configured by looking at the output of the browser's Java console, and make sure there is an entry for each of the ports which the Netlet should be listening on.


If the Java Console output indicates a bind error with port 80, the service already listening on that port must be disabled prior to connecting remotely with Exchange.

To Create a DNS Entry Which Will Publicly Resolve the Exchange Server Address to the Loopback Address

The DNS resolution must be made from a public DNS server. Most companies have internal subdomains which are subsets of their external second-level domains. In this case, an entry must be added to the SOA of the second-level domain to resolve the fully qualified Exchange server address to localhost.

The following procedure uses BIND 8 as an example of how to create a split DNS. If you are using a different version, the procedure will differ.

  1. Use BIND 8 (using int as a fictitious subdomain of sun.com), and perform the following steps:

    1. Add a zone entry for to the BIND config file (/etc/named.conf):

    2. ////////////////////////////////////////////
      // Zone info for int.sun.com domain
      zone "int.sun.com" in {
          type master;
          file "named.sun_int_hosts";
          // Restrict zone transfers to localhost
          allow-transfer {; };
    3. Create a Start of Authority in the hosts file:
    4. @    IN   SOA   int.sun.com.  
                  101     ; serial number
                  3600    ; refresh
                  600     ; retry
                  2073600   ; expire
                  3600   ) ; minimum TTL
          IN   NS   ns-sun.int.sun.com.
      ; hostname of Exchange server
      exchange-server     IN   A
    5. Push DNS maps:

    6. # pkill -HUP named
    7. Test lookup:

    8. # nslookup exchange-server
      Server: ns-sun.int.sun.com
      Name:  exchange-server.int.sun.com


For internal testing purposes, the mapping can be done by adding an entry in the client's hosts file (c:\windows\hosts). For example: exchange-server # Fully qualified address of Exchange server

To Create a Link to Launch OWA Which Will Not Be Rewritten on the Portal Desktop:

  1. Edit the display.template file (located in the ./iwtBookmarkProvider directory.

  2. See "Obtaining the Scripts and Tools for this Article" on page 3).

  3. Change the value of exchange-server to the fully qualified URL of your Exchange host.

  4. Note the use of top.window.open instead of window.open to avoid the link from being rewritten. This obviously won't work if top.window.open is already in the Gateway profile.

  5. Copy the display.template file to /etc/opt/SUNWips/desktop/iwtBookmarkProvider/display.template or to your own custom templates directory.

  6. Restart the Portal Server and Gateway component.

  7. Log in to the Gateway and verify that the link exists and works (FIGURE 1).

  8. NOTE

    To create a single logout, use the exWin handle from the LogOut link defined in menubar.html template file in:


    If there are multiple Exchange servers, the Netlet rule can be made dynamic, and links can be created directly from the desktop which will launch the Netlet. An example is included in the ./iwtBookmarkProvider/display.template2 downloadable file.

    Figure 1FIGURE 1 Example of new Bookmark Provider


This solution makes use of the popular practice of implementing a split DNS. By using a split DNS, the internal network IP addresses are not exposed, and by mapping the Exchange entry to localhost, the result is that would-be wrongdoers will simply end up talking to themselves. If exposing a single hostname is still a problem, a reverse proxy can be used in front of the Exchange server, and the Netlet rule can be configured so the traffic will be directed to the proxy instead of to the Exchange server. This allows the proxy to perform the correct hostname resolution and forward the request. This solution is ideal for customers whose end users require the full feature set of Exchange but cannot use the Outlook fat client recipe. It is also advantageous in situations where the Gateway profile has already been considerably modified, but Exchange is the primary application that remote users require. Beefy Gateway hardware is also recommended for this recipe. A proxy might also be a good solution if the internal DNS is not a subdomain of the external DNS and when the domain is unregistered.

  • + Share This
  • 🔖 Save To Your Account