How to create multiple instances of OWA

 

Creating multiple Outlook Web Access instances is a great way to assign users different sets of OWA features and/or give file share access to users who need it — without giving everyone in your organization the same access. This tip explains a method that can be used in any version of Windows, although some steps are platform-specific.


Here are five initial configuration steps that you can use to create different OWA instances on any Windows version.

  1. Assign an additional IP address to your client access server

You don't have to install additional network interface controllers (NICs) onto the server, but you can. Windows allows you to bind multiple IP addresses to a single NIC.

  1. Create a new website

OWA is a Web application that depends on Internet Information Services (IIS). When you install the Client Access Server role, Exchange creates multiple IIS virtual directories within the server's default website.

You can manually add more virtual directories to the default website, but limitations within Exchange Server prevent you from creating additional Exchange-related virtual directories. Therefore, you'll need to create a dedicated website for each additional OWA instance that you plan to create.

As a part of the site-creation process, you must bind an IP address to the site; each site should have a unique IP address. After you assign an IP address to the server, create a DNS record that allows users to access the new website using a new domain name.

When you create a website through IIS, its virtual directory maps to a physical folder on the server's hard drive. Note which folder is being used as the site's home directory.

  1. Create a new virtual directory

Now that you've created a site to host a new OWA instance, you're going to need to create the necessary Exchange virtual directories within that site. At the very least, you need to create the OWA virtual directory. You may also want to create other directories depending on which Exchange Server versions your organization uses.

There is an Exchange Management Shell cmdlet you can use to create the virtual directories. There are various switches that can be used with this cmdlet, but let's create a virtual directory using the following command:

New-OWAVirtualDirectory –Name "owa" –Website "Contoso.com"

This command creates a new OWA virtual directory and names it OWA. It also binds that virtual directory to the IIS website Contoso.com.

Note: In your organization, replace Contoso.com with the name of your new website.

  1. Assign users to specific websites

Once you've created the new virtual directory, now you can assign users to individual instances of OWA. Unfortunately, neither Exchange Server nor IIS allow you to grant or deny access to specific virtual directories. However, IIS virtual directories map to physical folders on the server's hard drive, making it possible to manage security at the NTFS level.

  1. Use segmentation to disable OWA features

Open the Exchange Management Console and navigate to Server Configuration -> Client Access, then select the Outlook Web Access tab. You'll see a separate listing for each OWA instance that you created. This makes it possible to manage each OWA instance separately.

If you double-click on a specific OWA instance, the console will display a properties sheet for that instance. Go to the properties sheet's Segmentation tab to enable or disable features within that instance of OWA without affecting other instances. Other property sheet settings are also OWA instance specific.

This technique can be used to make other changes within OWA. For example, you can use these steps to create personalized versions of OWA for individual departments within your company. You would just need to modify the HTML code or image files within an OWA instance. You could also use these steps to regenerate Exchange Server's virtual directories if they became corrupted.

 

Tool recovers deleted Exchange Server 2007 public folder data

It’s likely that one day a user will accidentally delete a public folder, prompting a frantic help desk call. Recovering the folder probably won’t be a big deal, though, if your backup application performs granular backups of the public folder database. Unfortunately, many backup apps don’t do this.

Although there are a few ways to recover public folder data, using the PFDAVAdmin tool is the easiest way. This tip explains how to use the tool.

Exchange Server has a retention period for deleted items. Therefore, a public folder isn’t immediately removed from the database when it’s deleted. During the retention period, deleted items remain in the database, but are inaccessible through normal operations.

http://media.techtarget.com/searchExchange/images/spacer.gif

http://media.techtarget.com/searchExchange/images/spacer.gif

http://media.techtarget.com/searchExchange/images/spacer.gif

The first step to recover a deleted public folder is to find out what the retention period is on the public folder server. To do so, open the Exchange Management Shell and enter the following command:

Get-PublicFolderDatabase FL

When you enter this command, it returns a lot of information about your public folder databases (Figure 1), including the deleted item retention time. Exchange Server 2007’s default deleted item retention time is 14 days, but this value can be adjusted.

The DeletedItemRetention setting displays the amount of time you have to recover the public folder
Figure 1. The DeletedItemRetention setting displays the amount of time you have to recover the public folder.

After you’ve checked the deleted item retention time, the next step is to recover the folder. There are a ways to do this, but I recommend downloading the PFDAVAdmin tool onto a management computer, not your Exchange Server.

Do NOT install this utility on your Exchange Server. The PFDAVAdmin utility requires the .NET Framework, version 1.1. Exchange Server 2007 requires the .NET Framework, version 2.0, but most new deployments use version 3.0 or 3.5.

If you install.NET Framework, version 1.1 onto a server that’s already running version 3.0, you will break some of the framework’s registrations and cause problems for Exchange Server. This is why it’s best to install the PFDAVAdmin tool onto a management computer.

The PFDAVAdmin tool is fairly easy to use. Once you’ve installed it, open it and select Connect from the menu. You’ll then be prompted to enter the name of your Exchange Server and the name of a global catalog server. You must also enter a set of authentication credentials. Finally, make sure that the Connection section is set to Public Folders and click OK (Figure 2).

Select the Public Folder option
Figure 2. Select the Public Folder option and click OK.

Once your public folder tree appears, right-click on the top level public folder and select Show Deleted SubFolders (Figure 3). Deleted subfolders will appear in red.

The PFDAVAdmin tool displays your public folder tree.
Figure 3. The PFDAVAdmin tool displays your public folder tree.

To recover a deleted subfolder, right-click on the folder and then select Recover Folder. The word RECOVERED has been appended to the deleted folder’s name as a part of the recovery process. Rename the folder to complete the recovery process.

 


This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. Thank you.


Exchange 2010 Mailbox Move Improvements and Move request reporting futures

Exchange 2010 is shining in many areas, performance is one of the first noticeable changes and mailbox move has some improvements in Exchange 2010.

I believe most common scenario will be moving mailboxes from Exchange 2003 to Exchange 2010. If you heart about online mailboxes and excited about it this wont work for those who are migration from 03 to 2010 simply the future does not apply to Exchange previous versions except Exchange 2007 SP2 or higher

In an online mailbox move, the mailbox is moved while the end-users can still access their e-mail accounts and the account only locks out the user for a very brief time during the end of the process when the final synchronization occurs. Online mailbox moves are only supported between Exchange 2010 databases, and between Exchange 2007 SP2 and Exchange 2010 databases. You can perform an online mailbox move across forests or in the same forest.  Read more

  • You can't use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Exchange 2003 to Exchange 2010.
  • You can't use the Move-Mailbox cmdlets in Exchange 2007 to move mailboxes from Exchange 2007 to Exchange 2010.
  • When you move mailboxes, the user will lose the ability to view their message tracking information

The move process is performed offline, and end-users won't be able to access their mailboxes during the move

Perform the move from a server running Exchange 2010 by using the move request cmdlets in the Exchange Management Shell. You can't use Exchange System Manager on an Exchange 2003 server to move the mailboxes.

Understanding Move Requests

If you need to upgrade from Exchange 2003 to Exchange 2010 try ESDA * deployment assistant here

  • Exchange still moves mailbox in patch of four ( four move treats at one time).
  • New Move request in Exchange 2010 makes perfect sense to keep track who is being moved and ability to get quick report is making the move process even more efficient.

Port Query

Here is another real nice tool from Microsoft, it is portqueryui, the GUI version of port query. This toll becomes very handy in day to day operations. Using this toll also makes good understanding about ports being used by an application. If you did not download and played with portqueryui, go ahead and download it.

Some Ports need to be remembered

·         Protocol: LDAP

Port (TCP/UDP): 389 (TCP)

Description: Lightweight Directory Access Protocol (LDAP), used by Active Directory

·         Protocol: LDAP

Port (TCP/UDP): 379 (TCP)

Description: The Site Replication Service (SRS) uses TCP port 379.

·         Port (TCP/UDP): 3268 (TCP)

Description: Global catalog. The Windows 2000 Active Directory global catalog (which is really a domain controller "role") listens on TCP port 3268. When you are troubleshooting issues that may be related to a global catalog, connect to port 3268 in LDP

·         Protocol: DNS

Port (TCP/UDP): 53 (TCP)

Description: Domain Name System (DNS) is at the heart of all of the services and functions of Windows 2000 Active Directory and Exchange 2000 Server. You cannot underestimate the impact that a DNS issue can have on the system. Therefore, when service issues arise, it is always good to verify proper name resolution.

·         Protocol: SMTP

Port (TCP/UDP): 25 (TCP)

Description: Simple Mail Transfer Protocol, is the foundation for all e-mail transport in Exchange 2000 and 2003. The SMTP Service (SMTPSvc) runs on top of the IIS Admin Service. Unlike Exchange 2007. Exchange 2007 has its own SMTP stack and it is not part of IIS anymore. Microsoft finally rewrote the SMTP stack.