Using SSL with Outlook Web Access

One of the most frequent questions I see posted to both the newsgroup and the Microsoft public newsgroups is about setting up OWA (Outlook Web Access) to use SSL for security. This is especially important in a scenario where you are using a Front-end/Back-end configuration as Front-end servers only support basic authentication. This might not seem like a big deal at first, but when you realize that this means that information is being sent across the wire in an unencrypted format, you can see how important this becomes. Some administrators also want to be able to *force* users to a secure connection, rather than manually requiring them to type it in. Finally, a lot of folks want to use the functionality included with OWA that allows you to change a users domain password. We are also going to cover all of this, but be aware that this last step does require you to use SSL on your OWA server. Having said all that we will begin by actually enabling SSL on the Exchange Virtual Server. In order to do this, I used a digital certificate from my own CA that I installed into my network. You can get your certificate from a local CA or from any of the CA’s that exist out on the internet. Where the digital certificate comes from isn’t important. Installing it into the Exchange Virtual Server to enable SSL for OWA is what is important to us. We start by going into the Default Virtual Web Server through Internet Services Manager, as you can see in Figure 1.

Next up we go into the properties of the Default Web Server, as you can see in Figure 2.

From there, we go to the Directory Security Tab and select to install a new digital certificate. This launches the certificate wizard as you can see in Figure 3.Once you have stepped through the wizard you should be able to go in and view the properties of the new digital certificate that you have installed as you can see from Figure 4. If you would like an actual walk through of the Certificate Wizard you can find it here.

Exchange 2000 Address Lists and Views

Aright, now that the summer is over, I guess that it is time to get back to work and start writing articles again on a somewhat regular basis. The topic for this particular article is going to be address list views and is in part inspired by a question posted by one of our newsgroup readers. The reader was looking for a way to create a new address list, but set it up so that only specific users would be able to access it. Well, that is exactly what we are going to do here today, so lets go ahead and jump right into it! Our first screen shot is taken from within Outlook, showing the different address lists that are configured and accessible by our clients. What I am going to do is a two step process. First, I will go ahead and create a new address list and show how that is done. We will then verify that the address list is visible and accessible to the Outlook users by logging in and trying to access some information from within the address list. Then, I will go ahead and hide that address list from view so that only specific users with the appropriate permissions will have the ability to connect to or even see the particular address list in question. Sound fun? Well let’s give it a whirl then! The first thing I want to point out is the default address lists that are visible from within Outlook 2000. As you can see from the figure below, there is nothing out of the ordinary here, although I do already have one custom address list that I created called Demo. (ok, so there is something out of the ordinary!)


Now the first thing that I do is go to the machine that is running the ESM, and I open up Recipients, and then All Address Lists. This should display the different address lists that have been created or are created by default upon installation of Exchange 2000. You can see the list in Figure 2.


Exchange, DNS, and Internet Email

As most of you know, I haven’t been churning out the articles lately. I am in a little bit of a slump, and decided to do a light article this week to help me get back into the swing of things. I decided that one of the best places to start would be with one of the most frequent problems I see people having with Exchange 2000. The question that I probably see the most relates to setting up Exchange 2000 to access the internet. What I am going to talk about in this article is how to setup DNS to allow your Exchange 2000 server to access the internet, as well as how to use Nslookup to troubleshoot DNS settings. Obviously, I can’t cover all possible configurations, but I am going to try and cover the most basic configuration.

I am going to go with the understanding that most of you already have your Exchange Server installations completed. If not, then this isn’t the article that will cover that. For installing Exchange, take a look at one of my earlier articles. Now once you have Exchange 2000 installed, there isn’t much else you need to do on the Exchange side. Exchange is tightly integrated with Active Directory, but more importantly, it is very tightly integrated with IIS as well. This integration allows Exchange 2000 to connect to the internet without requiring any connectors to be installed or configured. This one is a little different, because previous versions of Exchange required a connector of some type to be configured. For example, Exchange 5.5 required an Internet Mail Service Connector (IMS) in order to access the internet.

Now there are a couple of different ways that we could configure DNS for our Exchange 2000 server. For example, I might be running DSL, with a firewall like Proxy 2.0 or ISA Server in place. This would mean that we would have a public IP on the external network card of the firewall. Now, if we were running our own DNS server, we could simply put the appropriate Host (A) and Mail Exchanger (MX) records into our DNS database. Now, when a client queried our DNS server, the record for our Exchange 2000 server would be returned, and the client would be able to communicate with our server. This is a simple configuration from the standpoint of DNS, although it would require additional work in order to get the Exchange Server communicating from behind the firewall. For additional information on how to configure this, see Q276388 and Q308599.

However, judging from the questions that I am getting, the majority of you aren’t setting up your servers in this type of environment. The majority of the questions that I am seeing are centered around small companies that are running a single Exchange 2000 server, and running their own DNS servers for internal purposes, but using an ISP for external name resolution. Although this situation is a little more complicated than our previous example, it is by no means impossible. Probably the biggest problem facing most people is a lack of understanding on how DNS works. For this, I recommend reading DNS and BIND, by Paul Albitz and Cricket Liu. You can find this book just about any place that sells books on technology. Another good resource would be the Windows 2000 help files, as well as the Windows 2000 Resource Kit.

Now lets get back to our problem. We have our Exchange 2000 Server installed, we have our internal DNS working, taking care of Active Directory and all its needs. So how do we configure it to allow our internal clients to be able to send email out to the internet, and also to allow internet users to send email to our internal users?

The first thing that we need to take a look at is how do we get our email out to the internet? In this case, setting up our internal DNS server to forward requests that it can’t handle to our ISP’s DNS server should do the trick. So what I would need to do would be to go into the DNS MMC, right click on the DNS server object, and go to properties, and then select the Forwarders tab. I would type in the address or addresses of my ISP’s DNS server(s), clicking add after each one. Now my DNS server will simply send requests that it can’t resolve out to my ISP’s DNS Server. This will allow my clients to get their email out to the internet, but at this point, I am only halfway done. I still need some way to give users access to my Exchange server. The trick here is that my Exchange server is running on my internal network, probably running on a Private IP address. So let’s take a look at how we can accomplish this task.

As a first step, we have to add the appropriate MX and A records to our ISP’s DNS Server. In this case, the records would point to the public IP for our company, typically the external interface of our firewall. Now, we would need to use something like Network Address Translation (NAT) in order to convert the incoming request and redirect it to our Exchange server. In my earlier example using ISA server, publishing Exchange from behind the ISA server allows you to accomplish this task with a minimal of effort, because ISA will forward the requests for Exchange to the appropriate address, allowing external clients access to our internal Exchange server.

Given that we have configured everything correctly, our internal clients should be capable if sending and receiving both internal and internet email. But how do we know that we setup DNS correctly? Enter Nslookup. Nslookup is a troubleshooting utility that allows us to query a DNS database for the presence of appropriate records, amongst other things. Now, for internal DNS, we can simply open up the DNS MMC console and verify that we have correctly configured the Forward and Reverse Lookup Zones. This is easy enough, because we are in charge of these zones, we manage, create and delete them. But what about our ISP’s DNS database? How do you know that they have correctly configured your A and MX records. The answer would be to do a simple query of their DNS database using Nslookup. From Windows NT 4.0, 2000, and XP, simply drop to a command prompt and type in Nslookup

Once you hit enter, you can now query the DNS database. In my case, I have typed in that I am looking for an MX record. The second option tells the Nslookup utility what domain name I am looking for. In this case, it is my business domain, The screen would look like this;


You can also see from looking at the second screen shot that I am querying my ISP’s DNS server, which is However, this ISP isn’t authoritative for this particular domain name, as you can see from the reply that has been returned. It does show that I do have a configured Mail Server, as well as the Name Servers for my domain.

So this is how I can see what is in my ISP’s DNS database, without having access to the physical DNS server. Obviously, there is a lot more to Nslookup than what I have shown here. For more information about this utility, simply type Nslookup and press Enter. Then type help and press Enter. You can also lookup Nslookup in Windows 2000 Help, or online at Technet.

That should just about do it for now. Hopefully this helps to shed some light on configuring your Exchange 2000 servers to access the internet, as well as the DNS settings necessary to make it work. Next week we will get back to our regular series, starting with a new Exchange 2000 article. Until next time, cya!

Creating Address Lists in Exchange 2000

In my last article, I had mentioned that we would be talking about Address lists the next time that we talked. Lets go ahead and take a look at the default address lists created in Exchange 2000, and how to create new address lists as well. The first thing that I want to cover is the default address lists that exist in Exchange 2000.


What I have done is opened the Exchange System Manager (ESM). I opened up Recipients, and then All Address Lists. The first thing that I would note, and one of the things that most people immediately question, is why you can’t see the actual addresses when you highlight one of the default address lists, like so;


This is by design. In Exchange 2000, unlike previous versions of Exchange, we are using LDAP (Lightweight Directory Access Protocol) filters to create the address list. In order to see what addresses fall under a particular address list, you must right-click on the address list in question, and select properties. From the General tab, select the Preview button, and the addresses that display will be the appropriate addresses for the particular address list in question.



As you can see, the first screen shot is the actual LDAP filter that is used to define the recipients in question. In this case, I have selected the All Users address list. The point of my showing the LDAP filter is not to get into an in-depth discussion on LDAP, but rather to illustrate what an LDAP filter looks like. For more information on LDAP, you can look here. Also, RFCs #1777 and #1960 can give you a good jump on what LDAP is and how to use it in your network. Having said that, we have uncovered one of the mysteries of address lists in Exchange 2000!! If you have been working with Microsoft Windows 2000 for a while now, one of the things that you have probably realized is that there have been many changes to the interface. The same thing holds true for Exchange 2000, and address lists are a great example of how things have changed from previous versions of Exchange. What I am going to do is create a sample address list to give you some ideas on how to create one. Keep in mind that there are many different options for creating address lists, and this article simply means to serve as a starter, so to speak, for some of the different things that we can do. In order to create an address list, we right-click on All Address lists, and select New, and then Address list, like so;


Next, we provide a name for our address list, and then we have to define the filter that we will be using for this particular address list. In my case, I have named my new Address list Demo, and the filter that I have defined filters my users based on their Department, specifically the Marketing Department. The next graphic shows the default Filter that appears when you click on the filter button;


What I am going to do is modify the default filter to only apply to Exchange Users and Contacts, and the only field that I am interested in is the Department field. Again, the only users that I want to have appear are those in the Marketing Department. The filter will look something like this;


On the advanced tab, I select Users, and then select Department as my field of interest. I select “Is Exactly” and then Marketing. I click on Add, and then Ok. I have now defined my new LDAP filter that will list only users in the Marketing Department. Now, let’s make certain that we understand the practical application of this. If I had a very large company with users all over the world, my company address list (aka, the All Users List) could grow quite large. Instead of requiring my users to go through thousands of users names and address lists, I could create an address list similar to the one that I have just defined, and it would only show users from the Marketing Department. This would make it easier for users in the Marketing Department to locate users anywhere in the world, because the Marketing users are a small subset of all the users in the organization. This could be repeated numerous times, until we had defined all the appropriate address lists we needed for our organization. Having said that, if we go into the properties of our new address list, and click on the Preview button (on the General Tab), we should see something like this;


Not quite the scenario that I described a moment ago, but it definitely helps to illustrate the concept involved! One thing that I should point out is that once you actually create your new Address list, there could be a delay between the time you create the list, and the time that it takes for your recipients to show up in the list. The Recipient Update Service (RUS) is responsible for updating this information, so that would be the point to start troubleshooting from should you have problems getting the list to update. For some additional information on working with Address lists in Exchange 2000, take a look at Q319213. Also, take a look at Q253828 for information on how the RUS works to update address lists in Exchange 2000. Anyway, that about wraps it up for today. Normally, I give you a hint about what my next article will be on, but that will not be the case this time around. All I can tell you is that I will be back next time with another article discussing working with Exchange 2000. Until then, cya!!

Exchange Recipient Policies

Ok, now that I have had a little bit of a break, I guess it is time to get back to the articles! Today we are going to talk about Recipient Policies. Not necessarily the most glamorous feature of Exchange 2000, but definitely something worth knowing about. In Exchange 5.5, similar functionality was found in the Site Addressing object. However, as you will see, Recipient Policies in Exchange 2000 are much more flexible than Site Addressing was in Exchange 5.5, as well as having additional functionality to boot. The first thing that we will look at will be where we go to create our Recipient Policy, which is the Exchange System Manager (ESM). Once we open up the ESM, we will see on the right hand side the Recipient Policy container, like so;


When we expand the Recipients container, the first thing listed under it should be our Recipient Policies, with the Default Policy listed over in the right hand pane as you can see here.


Now what we are going to do is take a look at how we create a new Recipient Policy. In my case I have decided that several of my users require an additional SMTP address so that they can continue to receive email from their old address as well as their new address. I right-click on the Recipient Policies container, and I should see something like this;


Now I can go ahead and configure my settings for this particular policy. As we can see, the first thing we must configure is a name for the new policy. Once we have specified that, we can actually get on with configuring the properties that will really matter as far as this policy is concerned. As I mentioned before, my goal was to create a secondary address that would be accessible by some of my users that have come over from a merger with another company. After defining a name for my policy, I select Modify from the General Tab, and this will allow me to create my LDAP filter that will be used to define what users, groups, or objects my new policy will effect. The screen should look like this;


You should notice a couple of things about this particular utility. First off, it is the same utility that we can use to search through Active Directory to locate objects. Secondly, there are two parts to the search. First, we specify what type of object we want to find from the list box at the top of the dialog box, and then we select what type of recipients we want to filter, based on our earlier selection. You should notice that the available selections change, based on what you select from the Find drop down box. For example, if I wanted to filter based on Group Membership, I could create a filter similar to the following;


In this case, you should notice that I defined Users, Contacts and Groups as the focus of my search. I then went to the Advanced tab, and further stipulated that I only wanted to find a group called Administrators. In this way, I have complete flexibility and customizability when it comes to creating my Recipient Policies. In my case though, I don’t want to filter based on Group Membership. Instead, I would like to filter my recipient addresses based on the defined value listed in the City field for the user object. To do so, I would define the following filter;


This should have the intended effect that I am looking for, in that it will allow me to define a secondary SMTP address that these users will be able to use in addition to the default address generated by the Default Recipient Policy. One thing that I can do to make certain that my new Recipient Policy is working correctly is to use the Find Now button from the filter dialog box to make certain that my LDAP filter is working properly. As you can see from the following graphic, my filter is working just fine.


If you get to this stage and when you select Find Now, nothing appears in the results window, you need to refine your LDAP Filter. You might have defined the scope of your search too narrowly, or you could be attempting to filter based on a non-defined attribute. Once you redefine your LDAP Filter, try using the Find Now button again to ensure that you are seeing the objects that you want your new policy to apply to. Given that your filter is now working properly, we will want to apply our filter changes by selecting OK, and going over to the E-Mail Addresses tab. One thing that I should note, you will receive a warning message after creating your filter. The message simply reminds you that you have to select to Apply your policy after creation in order for it to take effect. Once we are on the E-Mail tab, we will create a new SMTP address for the recipients that we defined in our LDAP filter earlier. We select the SMTP address to highlight it, and then select the modify button. What we should see next is something that looks like this;


Now I have defined the actual SMTP address that I want to have applied to my users defined in my new Policy. I select OK, and I should receive the following warning;


Select Yes, and then we will need to Apply the Policy. Over in the right-hand pane, we right-click on the appropriate policy, and select Apply This Policy Now, as shown;


Now when I look at the properties of my recipients that have been effected by my new policy, I should see that they have a new address listed, and in this case it has been set as the Primary address for the recipients I have defined.


As we can see, my two recipients that were defined in the LDAP filter I created when I defined my new policy will both have a new SMTP address in the format This will allow them to continue to receive email from both their old domain ( as well as their new domain( You should note that because the policy I defined has a higher priority than the Default Policy, the new SMTP address was automatically generated as the Primary address. If I simply wanted to add a secondary address to all the users in my organization, but still wanted to maintain their address as the primary address, what I would have wanted to do was modify the existing Default Policy. One thing that you should notice about the Default Policy as well is that although you can modify the E-Mail Addresses tab, you cannot modify the LDAP filter! This is by design. The basic premise here would be that modifying the Default Policy is fine if you want the changes to apply to everyone in the organization, but if you want the changes to only apply to a specific group of users, or Organization Unit, or Administrative Group, then you would need to create a new Recipient Policy. One last thing to note about Recipient Policies. If I remove a policy that I have previously defined, it does not remove the E-Mail addresses that were defined in that policy. For example, we only had one custom defined Recipient Policy, so deleting it would leave us with only our Default Policy. This would mean that our two users should go back to having as their Primary address.


As you can see, the addresses themselves have not been removed, but the Primary Address has been reset to For additional information on Recipient Policies, see Q319201. Also, I mentioned earlier that one of the things that you could use Recipient Policy for was defining multiple domains that your Exchange Server could receive email from. This was handled in Exchange 5.5 from the Properties of the IMS object on the routing tab. For additional information on setting this functionality up, see Q268838.

Well, that about wraps it up for this weeks article on Recipient Policies. I hope that you have found the information useful. When we come back next week, we are going to take a look at Address Lists in Exchange 2000 and how we define them. Until next time, cya!!

Creating Users, Contacts, and Distribution Groups

This week we are going to change gears, moving away from planning to talk about creating recipients in Exchange 2000. We have four types of recipient objects that we can create in Exchange 2000, including mailbox-enabled recipients, mail-enabled recipients, contacts, and distribution groups. We will start with mailbox-enabled recipients, which have a Windows 2000 user account, and an Exchange 2000 email address. Before we actually create our users, we will have to look at the administrative utilities we will be using in order to create our users. We will see that for creating and managing our Exchange recipients, most of our tasks will be accomplished from within Active Directory Users and Computers (ADUC). The ADUC we will use will have to have the ESM (Exchange System Manager) installed on the same system in order for us to manage our recipients from there.

Once we have the proper administrative tools in place, we can begin to create our mailbox-enabled recipients. How we go about this will depend on whether or not we already have a user account created in ADUC. In our case, we will first look at creating a new mailbox-enabled user from scratch, and then we will look at mail-enabling an existing user account. Like creating a user account in Active Directory (AD), we first want to decide where we want to create the new user object that we will be mail-enabling.

Alright, enough introduction…let’s take a look at mailbox-enabling a new user obect in Exchange 2000. I have selected the Users container in ADUC, right-clicked, and selected New User.

Exchange 2000 Administrative Groups

As promised last week, we are going to spend this week taking a look at Administrative Groups. This is a new construct in Exchange 2000, although the idea is the same as it was in previous versions. By that I mean that Administrative Groups are collections of Exchange 2000 objects that are grouped together for the purposes of managing permissions. Administrative Groups can include routing groups, public folder trees, policies, chat networks, conferencing services, servers and monitors. This allows for administrative delegation across your Exchange organization, something that you might require depending on the size of your Exchange implementation. This is a key to Administrative Groups, because if you are the only Administrator in your company, or you only have two or three Exchange servers, you might not need to define additional Administrative Groups. However, if your company consists of many locations, departments, divisions, or Exchange servers, then you might have a need for multiple Administrative Groups.

Another key point to consider is the fact that Administrative Groups are logical in nature. By this I mean that you can base your Administrative Groups on any aspect of your Organization that works for you. As I mentioned before, it can be function, department, geography, or the number of servers. How you divide your organizations administration will be entirely up to you. For example, if you had 30 locations around the globe, and a local administrator in each location, you could create an Administrative Group to reflect the 30 different locations, granting each Administrator control over the Exchange resources for that, and only that location. In other companies, you might see a more centralized administrative approach. This might dictate that individual Exchange functionality would be controlled by different groups. For example, one group might be in charge of Routing Groups, another group would manage Recipient Policies, and still another would handle Conferencing Services across the company. The choices are many and varied.

Administering Exchange 2000

Well, the time has come to actually start administering our new Exchange server. In a moment we will take a look at the default view afforded by the ESM (Exchange System Manager), and we will begin discussing some of the issues involved in managing an Exchange 2000 implementation. I don’t want anyone to think that we are done with installations, because at this point we have just begun. But for now we are going to just sit back and examine our new Exchange installation. One of the best tools to use for this task is the ESM.

The first thing that we should notice is that we won’t be using the Exchange Administrator anymore, at least not in a pure Exchange 2000 implementation. Our new best friend is the ESM (see above) and it looks something like this:


This is a little different from our old Exchange Administrator, and has some “hidden views” to boot, so we want to look at this utility fairly closely. To start with, we can see at the top of the heirarchy is the Organization object, which we called 2000ExTrainers. If you remember, that was the Organization name we declared back when we ran forestprep. Below that we have Global Settings, Recipients, Servers, Connectors, Tools, and Folders. This is the default view, so we will discuss what is inside each one of these containers, and then we will explore the ESM a little further.

What we are looking at here (under Global Settings) are the Internet format settings (where we can configure our MIME types) and the Message Delivery Tab, which allows us to configure incoming and outgoing message size for all messages, as well as Filtering Options for undesireable UCE (Unsolicited Commercial Email). Next up is the Recipients container, which contains recipient policies, address lists, and templates. We will be looking at the address lists in more detail later, when we learn how to create custom address lists, as well as recipient policies, what they are used for, and where we can create and configure them from. We can’t see them yet, but next up would be the Administrative Groups, if we had them set to display. By default, they are hidden, so we won’t see them in our default view. However, later on we will see how to make them visible, and also talk about a couple of different scenarios that affect your ability to either hide or view Administrative Groups. There is also the Server container which will contain all servers in your organization, and a System Policies container which also is not visible by default. In fact, the System Policies container has to be created to be visible, and can only be created by having the Administrative Groups view available. This container has all configured mailbox store, public store, and server policies defined in your Exchange Organization. Next up is the Connectors container which contains your GroupWise, Lotus Notes, X400, SMTP, cc:Mail, MS Mail, and DirSync connector objects. Keep in mind that if you also have routing groups configured and set to display, connectors will also be visible within the corresponding routing group. Finally there is the Tools container which contains the Site Replication Services, allows you to track messages, and gather Monitoring and Status information.

ForestPrep and DomainPrep

Well, as promised last week, we are going to start off this week by finishing our look at Forestprep and Domainprep. After that, we will actually start through an actual installation of Exchange 2000 and see what’s new in the installation program. In case you have forgotten, you might want to look back at last weeks article for a quick review of how to run setup with either of these switches, as well as what each does.

When we were talking about Forestprep, we mentioned that this process was responsible for extending the AD schema for the introduction of the first Exchange server into our organization. The requirement to run Forestprep was to have both Schema admin and Enterprise Admin permissions. But in a smaller organization, you might be all of those things, as well as the Domain Administrator and the local administrator to boot. If this is the case, then you might not want to run forestprep as a separate process, but instead just run the installation program directly. You can do that, of course, but just be aware that the installation program will appear to take a long time to run, and it is because it will be running forestprep in the background. There is no way around extending the schema before introducing the first Exchange server into your Windows 2000 environment; the forestprep switch actually makes over 1800 changes to the schema of AD!! It is simply a question of whether you want to run forestprep by itself, or run it during the installation of the first Exchange 2000 server.

Installing Exchange Server 2000

Before we actually start our Exchange installation though, we need to talk about the rights required to install Exchange 2000 into the network. Exchange 2000 was the first Enterprise application designed by Microsoft to take advantage of the extensibility of the Windows 2000 Active Directory schema. By introducing Exchange into our network, we will now have a directory that understands mailboxes and virtual servers, amongst other things. In order to accomplish this task, we need an account that has the appropriate rights to modify the schema of Active Directory. This requires an account that is a member of both the Schema Administrators and Enterprise Administrators groups. The user must be a member of the local Administrators group as well.

Now this presents a quandry, because in a typical Enterprise environment, the number of users that will be in those first two groups is (or should be) extremely small. It is a quandry because typically, the Exchange Administrator will not be a member of either of those two groups. So how can we extend the schema if we aren’t a member of the appropriate groups? Enter ForestPrep. Running setup with the ForestPrep switch will allow an Enterprise admin to extend the schema of AD, without actually performing an installation of Exchange 2000. By completing this step, the Enterprise Administrator has extended the schema to understand the new object classes and attributes that will be used by Exchange 2000. When they are finished, we will be one step closer to staring the installation of our first Exchange 2000 server.

There are a couple of things to consider when running setup with the ForestPrep switch. We have already covered the rights issue. There is also the issue with spelling. Believe it or not, if you run setup with the ForestPrep switch, and don’t spell ForestPrep correctly, it will launch the full blown installation program and attempt to install Exchange 2000. I will be showing you the screens from ForestPrep later on in this article, and will point out what to look for.