SideBar    Why Host with OWA?

Open the Hosting OU's Properties dialog box, and go to the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object check box. When you receive a prompt asking whether you want to copy, remove, or cancel the existing permissions, click Copy. To prevent native users from accessing the OU, select the Authenticated Users group, then click Remove. Click Add to open the Select Users, Computers, or Groups dialog box. In that dialog box, select the AllUsers group, click Add, then click OK to close the dialog box. Click Advanced to open the Access Control Settings dialog box. Go to the Permissions tab, select AllUsers in the Permissions Entries box, then click View/Edit. Confirm that only the List Contents and Read All Properties check boxes are selected. Click OK to close the dialog box, then click OK to accept the changes.

Separating Hosted Users
In a typical hosted environment, you want to prevent users in one hosted OU from seeing information about other hosted OUs or your hosting organization. To set up these types of restrictions, use an account with Exchange Full Administrator rights to log on, then launch Exchange System Manager (ESM). Locate the All Address Lists object under the Recipients node. Open the object's Properties dialog box and go to the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object check box. When ESM prompts you to choose whether to copy, remove, or cancel the existing permissions, click Copy. Select the Authenticated Users entry in the Security tab's Name list, then click Remove. Next, select and remove the Everyone entry. Click Add and add the AllUsers group, then give that group Read Properties, List Contents, and Open Address List permissions.

Next, delete the All Users, All Groups, All Contacts, and Public Folders address lists from the Recipients\All Address Lists node in ESM. (You'll create OU-specific versions later.)

To set permissions on the default Global Address List (GAL), select the Default Global Address List object under the All Global Address Lists node. Turn off inheritance, copy the existing permissions, and remove the Everyone and Authenticated Users entries.

I suggest that you also use ESM to restrict permissions to modify top-level public folders and the Internet newsgroup hierarchy. (This restriction is a good idea whether or not you operate a hosted server because it prevents users from creating an excess of public folders at the top layers of your hierarchy.) First, locate the Public Folders container (under Administrative Groups\Folders). Open the container's Properties dialog box and go to the Security tab. (If you don't see the Security tab, see the Microsoft article "XADM: Security Tab Not Available on All Objects in System Manager" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q259221 for instructions about accessing the necessary settings.) Click Add and add the All Users group to the top-level public folder hierarchy, then click Advanced to open the Access Control Settings dialog box. Click Add to add a Deny ACE for the Create Top Level Public Folders permission. Next, open the Internet Newsgroups object's Properties dialog box and go to the Permissions tab. Edit the permissions to assign the None role to the Default and Anonymous entries so that Default and Anonymous users have no permissions. Then, clear the Folder Visible check box.

Configuring OWA
By default, all users can access OWA through a standard URL (http://servername/exchange). However, you might prefer to force hosted users to go to an OU-specific virtual directory. Doing so is easy: Disable access to the default /Exchange virtual directory, then create a new, separate Microsoft IIS virtual server and add virtual directories to that virtual server.

First, open the MMC Internet Services Manager snap-in. Open the Exchange virtual directory object's Properties dialog box, go to the Virtual Directory tab, then clear the Read, Write, Script source access, and Directory browsing check boxes. Repeat this process for the Public virtual directory object.

To create the new virtual server, launch ESM, expand the HTTP object (under the target server's Protocols node), then right-click the Exchange Virtual Server object and select New Virtual Directory to create a new virtual HTTP server. Give the directory an appropriate name (e.g., the name of the OU whose mailboxes the virtual directory will serve), and select the Mailboxes for option in the Exchange Path section, as Figure 1 shows. If you permit basic authentication for your Web servers, use the Internet Services Manager (ISM) to set the directory's default authentication domain to "\." To do so, open your Exchange server's Default Web Site object's Properties dialog box and go to the Directory Security tab. Click Edit in the Anonymous access and authentication control section to open the Authentication Methods dialog box. Click Edit in the Authenticated access section, then enter "\" as the domain name.

When you're finished, use the same process to create a new virtual directory for each public folder. Use public somewhere in the directory name so that users will know what the directory is for.

Creating Hosted OUs
Now for the fun part: creating OUs for each of your hosted organizations. Open the Active Directory Users and Computers snap-in, and create an OU under the Hosting OU. I usually use the full domain name of the hosted organization (e.g., limestone-redcross.org) as the name for the new OU.

Create a global security group in the new OU. Give the group a name that shows that the group is for all users of that OU (e.g., allusers@limestone-redcross.org). When prompted, give the group an email address; remove the domain suffix (e.g., .org) from the address. Open the group's Properties dialog box and go to the Member Of tab. Click Add, select the AllUsers group, click Add, then click OK. This step is necessary so that the group that holds the user accounts will have permissions on the hosted organization's OU.

Open the new OU's Properties dialog box, go to the Security tab, and remove the Authenticated Users and Everyone groups. Add the new security group, then select the group and the Read check box in the Permissions list's Allow column.

Create a second global security group for the hosted organization's administrators; name this group something like admins@limestone-redcross.org. Give the group an email address.

Right-click the new OU and select Delegate Control to launch the Delegation of Control Wizard. Use the wizard to delegate control over the OU to the new administrators' security group. Delegate the following tasks: Create, delete, and manage user accounts; Reset passwords on user accounts; Read all user information; Create, delete and manage groups; and Modify the membership of a group.

Open the MMC ADSI Edit snap-in and open the new OU's Properties dialog box. (Look for the OU object under Domain NC\DC=yourDomain, dc=com, OU=hosting.) On the Attributes tab, which Figure 2, page 14, shows, select the uPNSuffixes attribute in the Select a property to view drop-down box, then add the domain name of the hosted OU in the Edit Attribute field. This action lets hosted users log on as user@domain instead of the old-style domain\user syntax. (For more information about using ADSI Edit, see Sean Daily's Windows & .NET Magazine article "The ADSI Edit Utility," http://www.winnetmag.com, InstantDoc ID 19626.)

Not Finished Yet
You've set up your Exchange server to permit access to a specified OWA virtual server, and you've created a container (i.e., the hosted OU) in which to put user accounts. But you still need to create the user accounts and configure the default address lists so that users in one hosted organization can't see the GAL of other organizations you host on the same server. I'll show you how to complete your hosting setup in my next article. In the meantime, I suggest that you review Chapter 8 of the Microsoft Exchange 2000 Server Hosting Series.

End of Article

Prev. page     1 [2]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

You briefly mention the front-end back-end topology and indicate just a couple of ports on the firewall separating the front-end and back-end need to be opened. It has been my experience that you have to open up quite a few more ports than what you have listed... In fact by the time we were done opening up the required ports to allow functionality between the front and back-ends there was no sense in even having the firewall separate the 2 VLANS. I almost want to say the reasoning was due to RPC traffic between the front and back-ends. I know there is no MAPI traffic comming through the front-end but there was still RPC communciation going on between the front-end and back-end exchange servers. Also you may want to clarify where the placement of the Domain controller should be... It does make a difference.

Gary Collins

Extremely hard to follow, no detailed instructions on some procedures (almost have to take a guess in some stuff), no reference about the ADSI editor (i think that it would be a good idea to mention that this editor is included with the Windows 2000 Server disk and how to install this tool. It took me over 1 hour to find what the heck was the adsi editor and where to find it). It would me MORE than valuable to add more pictures showing some extra screens on the complicated procedures.

After finishing this article/tutorial the mail hosting does not work at all.

Rodrigo Alarcon

 
 

ADS BY GOOGLE