A long time ago, in a continent far, far away from where I currently live….
There was a younger, fitter and better looking version of me. One of the few woes that this chap had, was that on a Friday afternoon he would be struggling to delete enough files off a server to allow that day’s event log archive process to run. Site Server 3.0 ( yes, I’m really dating myself now….) was used to replicate the DMZ logs to the archive server as it meant only a single TCP port had to be punched in the firewall. That was great. What was not so great was that it used an Access database engine to keep track of what it had replicated and what could then be deleted. The deletion process often failed leaving thousands of unwanted files behind on the staging server. It was these pesky remnants which stood between that younger version of me and a pint of Staropramen.
So you can see the motivation. Stay behind for hours manually truffling through thousands of directories trying to delete old files, or learn to script….
It came to pass that I got down and dirty with VBScript. Yes I could have done this using cmd, but VBScript was new and shiny, and also was something neat to learn! This helped bring balance to the force, and was also excellent at providing repeatable process to implement IT tasks. This included IIS ADSI modification scripts, AD user provisioning and also for Exchange 2000/2003 tasks.
VBScript was one of the main automation tools for Exchange 2003. It worked well, but you had to do pretty much everything yourself.
Want a function to search for a mailbox. No problem, just code it from scratch. Want to add a recursive search to the above function. No problem, just code it from scratch.
Want a function to search for a mailbox. No problem, just code it from scratch.
Want to add a recursive search to the above function. No problem, just code it from scratch.
PowerShell changed the game with Exchange 2007, and it became the weapon of choice. At last, simple things became simple tasks.
Want to see properties for a mailbox. No problem, just run Get-Mailbox Want to add a recursive search. No problem, just add –Recurse.
Want to see properties for a mailbox. No problem, just run Get-Mailbox
Want to add a recursive search. No problem, just add –Recurse.
Enough preamble – what’s this page for? I wanted to have a single place where I could aggregate links and other content that I could then easily refer back to. It is work in progress, and will change/evolve over time. I will try and post samples where possible to the TechNet galleries and link back to here.
Please do add a comment if there is something that you’d like to see added here!
This is a series of articles that I previously wrote. They discuss changes to scripting Exchange from 2003 to Exchange 2007/2010. Part 2 has a detailed breakdown of the mechanics involved in Exchange 2010’s remote PowerShell
Part 1
Part 2
Part 3
In addition to the articles mentioned above, there are other items that I have written with touch upon PowerShell. While this may be from a Windows platform perspective, they are still very useful. The easiest way is to list all articles that have a PowerShell tag.
Alternatively use the search tool on the right.
Articles with PowerShell tag.
PowerShell is self describing in that you can use PowerShell to find out more about PowerShell. This was covered in the Introduction article using the Get-Member cmdlet. Additionally we can also use Get-Help to retrieve extra information.
On this Windows 2008 R2 SP1 server, this returned 89 items. How do I know 89? I’m too lazy to count, so I just pipe to Measure-Object.
For example if you want to know the format of PowerShell’s FOR loop, simply run:
Get-Help about_for
There is a good page on TechNet with additional links
Exchange 2010 PowerShell Scripting Resources
For those who still think, in VBScript and then have to convert to PowerShell this is for you. And yes, I still have a habit of thinking of VBScript syntax…
For convenience, I have extracted the file from the bundle and you can download it from here directly.
Pat Richards – lots of one liner examples
Shay Levy – This post for Windows Live Writer formatting is interesting
Glen Scales Exchange Dev Blog – well worth a read!
Cheers,
Rhoderick
After seeing several posts and some folks discussing whether or not Exchange supports the Hyper-V Replica feature I thought it would be prudent to address the following:
For some background reading on Hyper-V and the Replica feature; the component poster and downloadable documents can be found in this post. In short the Hyper-V Replica feature tracks changes to the specified VHDs, then ships these changes to keep a copy of the virtual machine synchronised on a second host. Windows Server 2012 R2 will enhance this further. The diagram below from the replica whitepaper shows a 20,000 foot view.
In short, Exchange does not support the Hyper-V Replica feature. Exchange has a long history of supporting virtualisation from Exchange 2003 onwards. It is fully supported to install Exchange 2007, 2010 or 2013 as a virtual machine on Hyper-V, but using the Hyper-V replica feature is not supported.
The Exchange 2010 virtualization support requirements and Exchange 2013 virtualization requirements pages are rather detailed in what must and must not be done on an Exchange virtual machine or hypervisor. If what you want to do is not listed, then that should set an alarm bell off….
The Exchange virtualization support statement has never listed Hyper-V replica, though some of the Hyper-V content has alluded to running Exchange as a replicated VM. Some workloads have announced support for Hyper-V replica, which includes:
Jeff Mealiffe delivered a great session on Exchange & Virtualization at TechEd. You can find this session here, and a list of all of the other Exchange sessions here.
In his session Jeff highlighted what was supported and what was not supported. Here is his slide for Hyper-V replica.
Exchange has specific supportability requirements, and additional virtualization specific stipulations. Please see the system requirements page for the appropriate version. You can find them at the bottom of this post. The Server Virtualization Validation Program (SVVP) should also be consulted to ensure that the hypervisor is supported under SVVP.
So until the Exchange Product Group folks have signed off and stated that Hyper-V Replica is supported, please do not leverage it for Exchange VMs.
Update 28-10-2013: Added PowerShell example to install Desktop Experience
While working with one of my consulting colleagues recently on some Windows Server 2012 installations. There was an application requirement to install Media Player onto a couple of the servers. This met with some muttering and cursing from the nearby fabric covered box as the option to install the Desktop Experience feature is not as obvious as it was on Windows 2008 R2, highlighted below.
I’m sure there is an oxymoron in there if you look hard enough!! If you want to just drive the GUI to install the Desktop Experience feature through Server Manager you have to expand the User Interfaces and Infrastructure feature and select the Desktop Experience component. So yes, it’s a little bit more hidden but you don’t have to be Indiana Jones to discover it..
This is shown in the screenshot below:
So that’s all nice, but what if we did not know that the Desktop Experience feature was located in that area? PowerShell to the rescue!!!!
Probably my favourite installation features in Windows Server 2012 are the Get-WindowsFeature and Install-WindowsFeature cmdlets.
What makes these cmdlets even more powerful, is that they accept wildcards as input. So in our case we can look for something called *Desktop*
Get-WindowsFeature *Desktop*
That’s pretty neat, and we can then see exactly where the Desktop Experience feature is located. The same goes for the GUI options that are present in Windows Server 2012 R2:
We could then install it via Install—WindowsFeature.
So as an example, we could use the following PowerShell oneliner to install Desktop Experience:
Install-WindowsFeature Desktop-Experience
For those folks out there who used the Windows 2008 R2 cmdlets, you will have noted that I specified Install-WindowsComponents above and not Add-WindowsFeature.
This is because the cmdlet is Install-WindowsFeatures and Add-WindowsFeature is an alias to Install-WindowsFeature. We can see this with the Get-Alias cmdlet:
Using wildcards is neat, and can make administration quicker and faster. What makes this even more efficient is that Windows 2012 now has a ComputerName parameter so we can directly query a remote machine. Additionally we do not have to manually import the ServerManager module in Windows 2012 either. In the example below DC-1 is the local machine which then queries a remote computer called Server-1:
PowerShell is not installed by default onto a Windows 2008 R2 core installation. Most customers will install it unattended or manually since the addition of PowerShell was a great new Feature in Windows 2008 R2. One of the machines that was previously upgraded did not have PowerShell enabled on 2008 R2 and after the upgrade to Windows 2012 it was still not fully enabled.
OCLIST on 2008 R2 will show us the initial state, prior to upgrading
On Windows 2008 R2 the Sconfig tool was one way that PowerShell could have been enabled.
I noted that a clean 2008 R2 Core VM when upgraded to 2012 was not able to run PowerShell as the feature was not present.
Checking the installed components locally with DISM showed
Dism.exe /Online /Get-Features
Checking the installed components remotely shows that the PowerShellRoot is installed, but PowerShell itself is not installed.
To Check remotely from PowerShell we can use a separate machine, and we specify the –ComputerName parameter with the name of Server-10 which is the name of the upgraded 2008 R2 core machine.
Compare this to the below (a server with the GUI installed) and note that PowerShell is installed on the example below but not on the upgraded server shown above.
Since PowerShell is not installed we cannot use Add-WindowsFeature to install It locally, since it’s chicken and egg time….
DISM is still present so we can enable the feature using it:
DISM.exe /Online /Enable-Feature /FeatureName:MicrosoftWindowsPowerShell
Alternatively we could have used a remote Server 2012 machine, and specified the upgraded box using –ComputerName and installed PowerShell that way. This is shown below along with the –Restart parameter which automatically restarts the machine if required:
Logging off and back on to re-spawn the cmd prompt then allowed PowerShell to be launched.
One little cmdlet, but it’s so very powerful. You could change the above syntax to suit your requirements. PowerShell will show you the name of the feature, and now you can add it remotely and also restart the target machine when the installation is complete. As Bill & Ted would say – Excellent!! **
** PS – Looks like a third film is planned. Hopefully this will be better than the proposed Highlander reboot……
When Microsoft performs an Exchange Risk Assessment Program (ExRAP) with a customer there are several work items related to patching. We discuss how the:
Most customers have an appreciation for properly managing and maintain the above, though they may be lagging on critical OS patches for example. Having standardised server builds, with known good drivers is a great foundation for any service.
Hopefully you will have noted the omission of one critical aspect of the messaging environment. Even though it’s the thing that you spend a huge amount of your day in front of -- Outlook. I really don’t want to say how many ExRAPs have shown that customers are not properly managing their Outlook clients.
Let’s not focus on the looming end of support for Outlook 2003, rather examine one of the other popular Outlook builds in detail – Outlook 2010.
Unfortunately when troubleshooting or reviewing an environment I see examples like exhibit A on the left here.
Exhibit A is a classic example of an Outlook 2010 client that has had little love and attention. This client is in an unsupported state as Office 2010 RTM is no longer in support, and SP1 must be installed.
You may think, well big deal I don’t want to call Microsoft support anytime soon. But tell me how are you going to get security updates for a version of a product where security updates are no longer made by the vendor?
Additionally, fixes that are being developed will be coded against the currently supported builds of the product, so that means SP1 is a requirement to install a recent fix. This can be seen in the Outlook 2010 October 2012 update.
You will notice that a given version of Exchange will only support certain versions of Outlook. Take Exchange 2010 for example. It’s system requirements page pledges support for Outlook 2003, 2007, 2010 and 2013. It will *NOT* support Outlook XP, Outlook 2000 and all prior versions that are now coffee mat coasters in your office.
Traditionally this has been part of the mind-set that has led to this challenge. By Exchange 2010 simply stating that “Outlook 2010” is supported and not explicitly driving customers to update to a recent build, this has led to some apathy in updating Outlook.
This is changing however!! You will note that Exchange 2013 has some hard requirements in supported Outlook builds, again documented on the system requirements page:
This is due to the fact that having an Outlook client that is up to date certainly does improve the user experience, in addition to hard technical requirements so that Outlook can understand the new Autodiscover XML response tags. While on this topic please ensure that you review KB 2839517 -- Outlook is unable to connect to Exchange 2013 public folder or auto-mapped mailbox.
Update 9-6-2014: Please note the text at the Office 365 requirements page has changed. I've left the below in for reference purposes but as always follow the requirements that are documented in the service plan requirements.
The same is also true for Office 365. if you are an O365 customer please note the specified timelines.
The Office Update Center will quickly show us the latest builds for Outlook. Staying focussed on Outlook 2010 we can quickly locate the following:
For the differences between Cumulative Updates and Public Updates take a peek here.
Please note that I am not advocating slapping patches on, they will require the same level of diligence and change control as the updates that are installed onto Exchange.
And just to see all the work that is being done by the Outlook team, I’d encourage you to scroll down to the section that lists all of the released updates. Take a look at the fix list for a few updates and you will see how many issues have been put to bed!!
Another way to look at it would be print each of the updates off, post them onto the helpdesk wall and tell the helpdesk not to troubleshoot any of these issues coming in as you do not have the fix in place….
I would assume that most us will have a corporate wide software deployment mechanism to get deploy these updates, report on compliance and ensure the patch level is maintained. For smaller shops, they will need to ensure that Microsoft Update is used on a machine as the standard Windows Update will not offer up patches for other Microsoft applications.
Update 14-4-2014: The discussion of Outlook patching again comes to mind due to a recent issue with Outlook 2013. This is discussed in KB 2863911 Outlook 2013 profile might not update after mailbox is moved to Exchange 2013
While we are on the topic of making sure that Outlook is being fully managed, please also make sure that the settings required by your organisation are being configured on Outlook. Outlook has provided extensive support for Group Policy and it is easy to configure the correct client settings via GPO. For reference the downloads are here:
One of the top support call generators when Exchange 2010 was first released was the change in RPC Client Access where the Exchange server required encryption to be enabled on the Outlook profile. Outlook 2003 does not select this option by default. If the Outlook client had been fully managed by GPO then this option could have been enabled and support issues minimised.
Just like many Exchange designs miss the CAS Namespace planning aspect, a lot also skip over making sure clients are at a good build level. Make sure Outlook is being fully managed and updated in your environment! Doing so will help mitigate issues and lead to improved user satisfaction with your messaging services. By proactively staying aligned with the support lifecycle you ensure that you are in a position to deploy a fix or security update with minimal additional work.
Please don’t overlook Outlook! **
** Else you will make Ross’s kitty sad. And we don’t want that!!
“Should I install my Exchange 2010 server onto a Domain Controller?”
“What issues will I see by installing Exchange onto my DC?”
“Is installing Exchange on a DC supported?”
“Is this DAG member supported on a DC?”
These are phrases that enterprise customers do not normally say. They are more in the realm of SMB customers, or consultants who are working with one of these smaller customers.
For clarity, Small Business Server is out of scope for this article.
Update 8-1-2014: Added TechNet Exchange 2013 link
Hopefully this is one of the first questions that is asked in the Exchange on a DC discussion. What’s the answer? Well it’s the consultant’s answer; “It Depends!”.
A regular Exchange 2010 install, while not recommended, is supported. This is covered on the Exchange 2010 System Requirements page in the Directory Server Architecture section. For reference the relevant passage is:
For security and performance reasons, we recommend that you install Exchange 2010 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2010. After Exchange 2010 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.
The same holds true for Exchange 2013 as stated in its System Requirements.
Additionally there is now a page on TechNet to specifically discuss this for Exchange 2013.
If Exchange 2010 is a DAG member, or will be a DAG member, then this is not supported. The official TechNet statement on this configuration is buried under the Add-DatabaseAvailabilityGroupServer cmdlet which will add the Mailbox server to the DAG.
To add a Mailbox server to a DAG, the Mailbox server must be running Windows Server 2008 Enterprise or Datacenter Edition or Windows Server 2008 R2 Enterprise or Datacenter Edition and it must not belong to any other DAG. The Mailbox server must be in the same Active Directory domain as all other Mailbox servers in the DAG. In addition, the Mailbox server must not be configured as an Active Directory directory server.
For Exchange 2013, this is again located with its version of the Add-DatabaseAvailabilityGroup cmdlet:
To add a Mailbox server to a DAG, the Mailbox server must be running the Windows Server 2008 R2 Enterprise or Datacenter operating system or Windows Server 2012 Standard or Datacenter operating system and it must not belong to any other DAG. The Mailbox server must be running the same versions of the Windows operating system and Microsoft Exchange, and be in the same Active Directory domain as all other Mailbox servers in the DAG. In addition, the Mailbox server must not be configured as an Active Directory domain controller or global catalog server.
Exchange may not block you from creating a DAG from a Mailbox server that is installed onto a DC, but that does NOT make it a supported solution. But what about the regular Mailbox server? Since that is a supported option, that makes it a good idea, right?
Well, I’m able to drive my car with my knees but that still does not make it a great idea!
Think about what is happening and what potentially has to happen if you collocate Exchange and AD.
Exchange 2010 SP2 introduced the Address Book Policy (ABP) feature. For this to work the Address Book traffic must go through the Exchange server so that CAS can strip out and control access to the directory information. If this is not done then the user sees everything. When Exchange is installed onto a GC, the Name Server Provider Interface (NSPI) endpoint is not owned by Exchange – rather it is the underlying OS. So guess what? ABPs will not work as the traffic is not filtered by Exchange.
This is not intended to be an exhaustive list of the issues caused by installing Exchange onto a DC.
In addition to the System Requirements page, please also make sure that you have the Supportability Matrix bookmarked as well! If you follow them wisely, then you will not do unsupported things like install PowerShell 3.0 onto an Exchange 2010 SP2 server.
Here are the links for your convenience:
Update 12-7-2013: Please note there is an issue with Public Folder Permissions in CU2. Details here.
Update 29-7-2013: Please note CU2 has been re-released to resolve the Public Folder issue. Details here.
The Exchange team have announced the second instalment of love for Exchange 2013 RTM – Cumulative Update 2 (CU2) is now available on the download centre. Knowledgebase article 2859928 contains a description of CU2. As with CU1, it allows on premise installations to co-exist with Exchange 2007 and 2010.
As always check the Exchange 2013 system requirements to ensure that all support aspects have been met.
If you are installing the first Exchange 2013 server into your org please familiarise yourself with the issues around reported mailbox size increase and the potential impact from full OAB downloads.
Just as before you cannot re-introduce a down level Exchange role once the last one has been removed. For example if you want to maintain the capability to install additional Exchange 2007 servers ensure that you preserve at least one machine that has all the roles. This will allow you to add more Exchange 2007 servers in at a later date. The same also applies for Exchange 2010, once that role has been removed you cannot add additional servers back into the Exchange org
Exchange 2013 updates the build string visible in the management tools so you will see the version numbers change. This is one of my labs where you can see the different builds in PowerShell (click to enlarge)
and also in EAC (click to enlarge).
The previous versions are included for reference
Exchange 2013 RTM: 15.00.0516.032
Exchange 2013 RTM CU1: 15.0.620.29
Exchange 2013 RTM CU2: 15.0.712.22
The downloaded file name is Exchange-x64.exe as is the download for CU1. Please make sure you save then into suitably named folders!
As discussed By Greg Taylor and Scott Schnoll during their respecting TechEd 2013 sessions, some new features have been added. Note that all of the Exchange TechEd NA sessions can be found here, O365 sessions can be found here and Lync Sessions can be found here.
Exchange 2013 RTM CU2 increased the Enterprise edition per-server database limit from 50 to 100 databases. Ensure that you have sufficient CPU horsepower (or mice) to meet the requirements that all of these databases and CI instances need. You’ve been warned!
CU2 also provides a OWA Single Sign On (SSO) experience. For those people who are doing coexistence with Exchange 2007 and Exchange 2013 installs with multiple external OWA AD sites then the end user experience was less than peachy.
For the cynical folks out there, you will be saying that this was already in Exchange 2010. and yes cross site silent OWA was added in Exchange 2010 SP2. Though it should be noted how quickly the features were added to Exchange 2013! The redirect is a little different in Exchange 2013 RTM CU2 as:
<ExchangeSetupDir>\FrontEnd\HttpProxy\owa
<add key="DisableSSORedirects" value="true" />
CU2 adds the DAG management service. The same logging is present except the code was moved from the replication service to the DAG management service.
Managed Availability can now be throttled per group.
Malware filter rule cmdlets have been added to apply custom malware filter policies.
The issue around being unable to disable OWA access for a user has been resolved in RTM CU2, and KB 2835562 has been updated to reflect this.
The sizing guidance has been updated for Exchange 2013 RTM CU2 and this is reflected in the Exchange 2013 Server Role Requirements Calculator.
As with CU1, CU2 follows the new servicing paradigm that was previously discussed on the blog. The CU2 package can be used to perform a new installation, or to upgrade an existing Exchange Server 2013 installation to CU2. You do not need to install Cumulative Update 1 for Exchange Server 2013 when you are installing CU2. Cumulative Updates are well, cumulative. What else can I say,,,,
After you install this cumulative update package, you cannot uninstall the cumulative update package to revert to an earlier version of Exchange 2013. If you uninstall this cumulative update package, Exchange 2013 is removed from the server.
Note that customised configuration files are overwritten on installation. Make sure you have any changes fully documented!
What do I mean by that? Well, you need to ensure that you are fully informed about the caveats with the CU and are aware of all of the changes that it will make within your environment. Additionally you will need to test the CU your lab which is representative of your production environment.
Exchange 2013 RTM CU2 was noted to have an issue with the permissions of migrated public folders. The Exchange team has released an updated version of CU2 to address this. This replaces the original download for CU2.
The updated build is available from the Microsoft download centre. Knowledgebase article 2859928 contains a description of CU2. As with CU1, it allows on premise installations to co-exist with Exchange 2007 and 2010.
Just as before you cannot re-introduce a down level Exchange role once the last one has been removed. For example if you want to maintain the capability to install additional Exchange 2007 servers ensure that you preserve at least one machine that has all the roles. This will allow you to add more Exchange 2007 servers in at a later date. The same also applies for Exchange 2010, once that role has been removed you cannot add additional servers back into the Exchange org.
Please see the original post here for additional details on CU2 and installation considerations.
Exchange 2013 updates the build string visible in the management tools, so you will see the version details increment.
Exchange 2013 RTM CU2: 15.0.712.24