Customize the Exchange Management Shell as an Exchange administrator, it’s only a matter of time before you embrace the dark side and come to know the true power of shell. The Exchange Management Shell is the direct interface between you and the underlying PowerShell cmdlets that are used to query, configure, and manage Exchange. Getting comfortable with a command line interface after years of GUI work is a big shift for many admins, but if you start out slow, and work your way through things step by step, you’ll soon find that you are a PowerShell Jedi. Making something your own is the first step towards getting comfortable with it, so in this post, we’ll see how to customize the Exchange Management Shell to make it your own. Continue reading Customize the Exchange Management Shell

Moving to any cloud service that uses Federated Identities can mean needing to change the UPN suffix for your users. For years, companies have been using internal domain names for their Active Directory, and only registering the external domain names that they want to tie to web sites, email addresses, etc. With so few companies even using the User Principal Name for user logins, it has never been an issue until now.

Companies that want to outsource services like email to the cloud or other hosted solution providers while still maintaining control of user authentication, provisioning, password changes, and deprovisioning, have few options other than Federated Identity Management. As most use Active Direcotry, this means Active Directory Federated Services (ADFS). Office 365 in particular offers customers the option to federate user identities, enabling the company to provision/manage/deprovision users on their own AD, and to handle all authentication. This leads to better security for the company, the ability to deploy whatever password policy they wish, and users have one set of credentials for both local and cloud resources.

Continue reading How to change your UPN suffix with PowerShell

With hosted and cloud mail services growing in prominence, it’s no wonder we’re starting to see more coverage of these services on TheEmailAdmin.com. In my humble opinion, Office 365 is setting the pace for all the rest, and as the service matures, more and more resources become available for companies looking to move some or all of their email services to the cloud.

The one thing about Office 365 that tends to give many admins pause is the same thing that makes them shy away from upgrading to Exchange 2010 – the requirement to use PowerShell for some administrative work. While much of what you need to use PowerShell for in Office 365 will be given to you in a copy-paste ready format, and other admins may never use PowerShell on their own, preferring to deal with what they can get from a GUI or service ticket, the more adventurous (or advanced) admins know that to get real work done, you have to roll up your sleeves and drop to the prompt. And that is why this post presents some very useful web resources for those of you ready to take the plunge.

Continue reading Four PowerShell Resources for Office 365

There are many reasons why an organization would make the move to Exchange Server 2010. Features like email archiving, increased discovery capabilities, greater flexibility and the lure of anywhere access make this email solution a promising one.

However, these features are generally ones that are used to sell management on an upgrade or switch. For administrators, the PowerShell is usually a feature that gets them on board. Continue reading PowerShell Basics in Microsoft Exchange 2010

This may seem a strange way to open a post, but let me start by saying that I do not recommend doing any of what I am going to cover here. It’s not that what I am going to cover won’t work, or could cause your system to function incorrectly. Not at all. The reason I don’t recommend doing these things is because I don’t think you should ever restrict users from accessing email, in any way that they want to. I’ve blogged previously about how great ActiveSync is here and here , and you might also know how much I love OWA and will even support POP3 and IMAP, though I do prefer the secure versions.

However, in certain situations, some companies might wish to extend external access to email to a small subset of users, or they might wish to ensure that ActiveSync connections are only possible from corporate controlled telephones, and if you work for one of these companies, your boss may come to you and ask you to do this. In this post, for those of you who must restrict access to certain client services, we’re going to cover the Set-CASMailbox cmdlet.

Continue reading Restricting access to Exchange’s client access services

There are lots of tools available to the admin for creating new users in Active Directory, including Active Directory Users and Computers, the Active Directory Administrative Center, and the command line tools like dsadd and net user. When administering Exchange 2010, you will probably find yourself creating mailboxes using the GUI when you provision new user accounts, however, there are times where you need to create a mailbox outside of using ADUC. Whether there is a one off need, something happened during user creation that wasn’t quite right (like the user’s name was misspelled in AD,) you’re creating a resource or a shared mailbox, or you want to programmatically create user accounts and mailboxes with a script, the Exchange Management Shell (EMS,) or PowerShell to its friends, is a great way to go when you want to script this out.

Continue reading How to create user accounts and mailboxes with PowerShell

Microsoft Exchange Server 2007 ships with some useful tools for testing the health of the different server roles.

These tools come in the form of PowerShell cmdlets that can be executed from the Exchange Management Shell.

The tools are very handy both during implementation of new Exchange systems as well as when investigating faults.

General Tests

Test-ServiceHealth – tests the health of the Exchange services on the server and lets you know if any required services for the installed roles are not running.

Test-SystemHealth – this is the command line version of the Exchange Best Practices Analyzer, and will alert you to any error conditions or configurations that deviate from best practices.

Test-Path – this is not strictly an Exchange test.  Test-Path is useful when building scripts and is used to verify the existing of an element such as a file, folder, or registry key, returning a simple True/False answer.

Client Access Server

Several of the Client Access Server tests utilise a system-managed test mailbox which you must first create by running the new-TestCasConnectivityUser.ps1 script from C:\Program Files\Microsoft\Exchange Server\Scripts.

Incorrect Client Access Server configuration can cause a wide range of problems within an Exchange Server 2007 organization so these tests are essential during any Exchange implementation. Continue reading Testing Exchange Server Health with PowerShell