In this post I’ll walk you through how to use PowerShell to create a new folder under the users contacts folder in Exchange 2010. I imagine this will also work for later version os Exchange as the command still exists in Exchange 2016.. but I haven’t tested it.
The things you need to make this work are:
Rights to the users mailbox
CAS stole installed
Exchange PS-Snapin imported
If you have those 3 items, then it works fine.
So, the issue is that if you run the New-MailboxFolder command out of the box it wont work unless the snapping is installed so the first command you run from the Exchange Administrative Shell is
When importing into the other system, you may want to convert SMTP (uppercase) to smtp (lowercase) and similar for X400, X500 and SIP addresses or ad .tolower() to $address.proxyaddressstring when extracting the addresses above.
Exchange 2010 shipped just over a week ago so I thought it a good time just to walk through a quick and easy way to get Exchange installed on a single server. Note that this isn’t a guide to upgrading your existing environment, just walking you through how to get Exchange installed into a pristine environment.
In my lab I have a domain called philipflint.com and a domain controller called DC1. I’ll be installing Exchange on a server called EXCH1 with the CAS, Hub Transport and Mailbox roles. All servers will be running WIndows Server 2008 R2 Enterprise Edition for no reason other than that’s what I tend to install in my labs. Certainly, everything in this post will work on Standard Edition.
One trick that will save you time is installing the required pre-requisites. These are listed here. Simply find the list of roles you want to install an the operating system that will be hosting Exchange and copy and paste the commands.
As I will be running Windows Server 2008 R2 with all three roles on the server I first install the 2007 Office System Converter Pack found here. This is a very simple installation of the next, next, next variety. After installing the pack, we start PowerShell (See the blue Icon next to the start button) and then run the command Import-Module ServerManager. To do this, and run subsequent commands, we need to run PowerShell as an Administrator. Simply right click the PowerShell icon and choose “Run As Administrator“.
Powershell Icon above.
This imports the ServerManager cmdlts into PowerShell. Once this is done we can run the commands that install our pre-requisites. For a typical installation these are:
Once the pre-requisites are installed, the server will reboot. After rebooting we need to start an elevated PowerShell command prompt (by right clicking the icon and choosing “Run As Administrator“) and run the command Set-Service NetTcpPortSharing -StartupType Automatic. Now we’re ready to install. Simply insert the DVD or double click on setup.exe on the DVD drive.
The first step after installing the pre-requisites is to choose an installation language (Step 3 on the GUI). When you click on it you get the selection below.
I choose “Install only languages from the DVD“. You’re then free to move to Step 4 “Install Microsoft Exchange” !
The installation will start and take you through the guided installation wizard. First, click Next on the introduction screen.
Read and Accept the license agreement if you want to continue.
If you prefer to make Exchange a more stable product for all users, enable error reporting and click on Next.
For a typical installation, leave the selection at its default. Here, you can change the placement of installation binaries, For large scale or more secure systems you may want to move the binaries to separate spindles or a different location.
For more complicated installations, select Custom Exchange Server Installation. Even though I am going to perform a typical installation I show below the Custom Installation screen.
Notice the difference between Exchange Server 2007 and Exchange Server 2010 ? There are no choices for clustered mailbox servers as Exchange 2010 now uses Database Availability Groups (DAG) for replicating databases.
As this is a pristine installation, we’re now asked to give our Exchange Organization a name (this would not be the case if we were installing into an existing installation).
We’re then asked if we require a public folder database to support connectivity from Outlook 2003 / Entourage for Mac clients. Depending on your corporate policy you may want to create public folders but for a pristine implementation running up to date clients then I would consider not using Public Folders at all.
If your CAS servers (Outlook Web Access, Active Sync, Outlook Anywhere) are internet facing then you can enter the public URL for this service.
Again, if you want to improve future editions of Microsoft Exchange the sign up for the Customer Experience Improvement program.
The installation will then perform its readiness checks to ensure that the server meets the basic pre-requisites for installation of Exchange. You will no doubt note that I have not performed any schema , forest or domain preparation. I am installing Exchange as the forest root administrator and so installation will proceed as expected. For larger implementations then Active Directory may need to be extended and prepared from on one of the Domain Controllers. A note should be taken that, if we prepare the domain, no Exchange 2007 or earlier servers will be able to be added to the Organization.
You can now click on Install to install the binaries. When the installation has completed, check that everything installed OK and click on Finish
The Exchange Management Console will open but leave that for a bit and go back to the setup screen. The final choice is to Get Critical Updates for Microsoft Exchange.
Clicking on the link will take you to the Microsoft Updates site where you can agree to download updates for software other than just Microsoft Windows (i.e. Exchange Server). Simply follow the wizard through to update your software.
That now gets you to the point that you have a basic installation of Exchange. This doesn’t mean that you have a working copy of Exchange, we have merely installed the binaries on the server. In my next post I walk you through configuring Exchange for the first time.
Just a quick note – are you supported if you virtualise Exchange 2010 mailbox servers hosting Database Availability Groups ? The short answer is “yes”. The long answer is “Yes ….. unless you want to use Live Migration / XenMotion / VMotion … then you are NOT supported”.
To explain, DAG is a high availability strategy in and of itself. If you want to virtualise servers hosting DAG then you may but those servers should run on stand alone virtualisation hosts. Layering any sort of hardware higher availability on top of DAG high availability will invalidate your support. In truth, this shouldn’t be an issue as virtualisation only provides redundancy at the hardware level with Live Migration / XenMotion / VMotion whereas Exchange DAG provides hardware, O/S, binary and data redundancy (i.e. full redundancy) but you should take account of this in any plans you have for virtualising Exchange 2010.
When you read Microsoft’s sizing guides then the basic advice for mailbox servers, for example, is to use 4 processor cores for Exchange for every 1 Active Directory processor core (Exchange 2007 with AD running on 32 bit). However, the situation you often get is that the domain controllers exist in a data centre servicing many solutions or even in a server room servicing user logons and so you can’t really assign specific domain controllers to service just Exchange. Now, what you can do is tell Exchange to just use certain DC’s but this doesn’t stop those DC’s from servicing other requests. But, there is a solution ….. Active Directory sites.
As you know, Active Directory “knows” which Domain Controller to direct a logon request to by using the clients IP address and directing the request to a domain controller in the same site as the user (or another site assigned to the users IP subnet). But requests are directed to the “most likely” subnet or, to put it another way “best match” subnet. Where this leads us to is that you can use subnets in Active Directory Sites and Services to direct logon requests.
For example, your data centre may have the subnet 10.1.1.0/24 (10.1.1.0, 255.255.255.0) and you may have the following servers.
So, what we don’t want to do is just assign the subnet 10.1.1.0/248 to a site as this will not include Exchange2 and, indeed, will remove all DC’s from our server site. Similarly, we can’t just use 10.1.1.0/240 as a subnet as this will also include our backup server and, once again, all DC’s. That is, we could assign a more specific subnet to the Exchange “site” but, if needs be and for the purposes of this article, we can also assign individual servers. Below is an example of our site setup before we start with all servers assigned to the subnet OU.
The first thing we would do is create a new Site called, for example “Exchange” and, in this case, assign it to our default site link.
We then create a new Site Link to link the Exchange servers back to the Server site. We do this so that we can change the replication schedule as we will want “fast” replication between the DC’s in the Server site and in the Exchange Site (If required the sites can then be removed from the Default Site Link).
We can then create a series of new subnets, one for each server, and assign them to the “Exchange” Site.
In this way, individual servers can be added to the site until all servers that should be treated as one unit exist in the same site.
The Domain Controllers can then be moved to the Active directory site by right clicking the server in Sites and Services and selecting “Move”
This means that all the servers should perform lookups and any authentication against the domain controllers in their own local site. This technique can also be used in any other situation where particular AD servers have to be used by particular servers (for example when a certain level of domain controller must be used in a still mixed environment). All that remains is to change the site link to replicate rapidly.
By default, changes are not replicated between sites when the change is made (with the exception of urgent replication items such as password changes). Instead changes are replicated according to a schedule as defined on the site link. By default the replication interval is set to 180 minutes.
However, as these servers all sit on the same high speed network we can configure change notifications to traverse the site link in near real time as though the servers are in the same site. This is done by setting a value in Active Directory by using the ADSI Edit tool (installed by default in Windows 2008 R2 and part of the support tools pack in Windows 2003.
To enable change notification between sites
In ADSI Edit, expand the Configuration container.
Navigate to the Inter-Site Transports container, and select CN=IP . (You cannot enable change notification for SMTP links.)
Right-click the site link object for the sites for which you want to enable change notification (CN=Exchange Servers in our case), and then click Properties .
In the Select a property to view box, select options .
In the Edit Attribute box, if the Value(s) box shows <not set> , type 1 in the Edit Attribute box. If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3. In this case, as this is a new site link that we have set up then the value should be set to <not set> and so we can enter 1.
Click OK and the OK again and exit ADSI Edit.
Changes should now be notified across the site link with the same frequency as they would if the servers were in a single site (around 15 seconds for 2003 / 2008).