Exchange 2013 SP1 has now been released to the Microsoft Download Center!
The build number for Exchange Server 2013 SP1 is 15.00.0847.032
Update 5-3-2014: If you are using custom transport agents please see Third-party transport agents cannot be loaded correctly in Exchange Server 2013 The script you need to remediate the issue is linked from that KB, and is available directly from the download center.
Update 14-4-2014: As discussed in post “Patching Exchange? Don’t Overlook Outlook”, make sure to keep Outlook updated. KB 2863911 Outlook 2013 profile might not update after mailbox is moved to Exchange 2013
Update 14-4-2014: Please see KB 2958434 if deleting Exchange 2013 databases. Users cannot access mailboxes in OWA or EAS when mailbox database is removed.
As always please read the release notes! Exchange 2013 SP1 contains schema changes and you will need to go through testing and validation to ensure a smooth rollout!
Noted at the bottom of the Exchange Team Post the next Exchange 2013 update will be CU5. Thus we could call this CU4, but Service Packs mark an important milestone for support lifecycle events so this do think of this as a Service Pack!
You can download Exchange 2013 SP1 from here.
Scroll down below for details on each of these features!
KB 2926248 contains the description for Exchange 2013 SP1.
Windows Server 2012 R2 is now a supported operating system in Exchange 2013 SP1. Exchange 2013 SP1 also supports installation in Active Directory environments running Windows Server 2012 R2. For more information, see Exchange 2013 System Requirements.
Edge Transport servers minimize attack surface by handling all Internet-facing mail flow, which provides SMTP relay and smart host services for your Exchange organization, including connection filtering, attachment filtering and address rewriting. For more information, see Edge Transport Servers.
OWA customers can report missed spam in the inbox (false negative) and misclassified as spam (false positive) messages to Microsoft for analysis by using its built-in junk email reporting options. Depending on the results of the analysis, we can then adjust the anti-spam filter rules for our Exchange Online Protection (EOP) service. For more information, see Junk Email Reporting in OWA.
Microsoft Exchange Online and Exchange 2013 SP1 now support S/MIME-based message security. Secure/Multipurpose Internet Mail Extensions (S/MIME) allows people with Office 365 mailboxes to help protect sensitive information by sending signed and encrypted email within their organization. Administrators can enable S/MIME for Office 365 mailboxes by synchronizing user certificates between Office 365 and their on-premises server and then configuring Outlook Online to support S/MIME. For more information, see S/MIME for Message Signing and Encryption and the Get-SmimeConfigcmdlet reference.
Data loss prevention (DLP) Policy Tips are informative notices that are displayed to senders in Outlook when they try sending sensitive information. In Exchange 2013 SP1, this functionality has been extended to both the desktop version of Outlook Web App and the mobile version (named OWA for Devices). You’ll see it in action if you have an existing DLP policy with Policy Tips turned on for Outlook. If your policy already includes Policy Tips for Outlook, you don't need to set up anything else. Go ahead and try it out!
Not currently using Policy Tips? To get started, Create a DLP Policy From a Template, then add a policy tip by editing the policy and adding a Notify the sender with a Policy Tipaction.
Deep content analysis is a cornerstone of DLP in Exchange. Document Fingerprintingexpands this capability to enable you to identify standard forms used in your organization, which may contain sensitive information. For example, you can create a fingerprint based off a blank employee information form, and then detect all employee information forms with sensitive content filled in.
SP1 provides an expanded set of standard DLP sensitive information types covering an increased set of regions, which makes it easier to start using the DLP features. SP1 adds region support for Poland, Finland and Taiwan. To learn more about the new DLP sensitive information types, see Sensitive Information Types Inventory.
Deploying and configuring Active Directory Federation Services (AD FS) using claims means multifactor authentication can be used with Exchange 2013 SP1 including supporting smartcard and certificate-based authentication in Outlook Web App. In a nutshell, to implement AD FS to support multifactor authentication:
Install and configure Windows Server 2012 R2 AD FS (this is the most current version of AD FS and contains additional support for multifactor authentication). To learn more about setting up AD FS, see Active Directory Federation Services (AD FS) Overview
Create relying party trusts and the required AD FS claims.
Publish Outlook Web App through Web Application Proxy (WAP) on Windows Server 2012 R2.
Configure Exchange 2013 to use AD FS authentication.
Configure the Outlook Web App virtual directory to use only AD FS authentication. All other methods of authentication should be disabled.
Restart Internet Information Services on each Client Access server to load the configuration.
For details, see Using AD FS claims-based authentication with Outlook Web App and EAC
SSL offloading is supported for all of the protocols and related services on Exchange 2013 Client Access servers. By enabling SSL offloading, you terminate the incoming SSL connections on a hardware load balancer instead of on the Client Access servers. Using SSL offloading moves the SSL workloads that are CPU and memory intensive from the Client Access server to a hardware load balancer.
SSL offloading is supported with following protocols and services:
Outlook Web App
Exchange Admin Center (EAC)
Outlook Anywhere
Offline Address Book (OAB)
Exchange ActiveSync (EAS)
Exchange Web Services (EWS)
Autodiscover
Mailbox Replication Proxy Service (MRSProxy)
MAPI virtual directory for Outlook clients
If you have multiple Client Access servers, each Client Access server in your organization must be configured identically. You need to perform the required steps for each protocol or service on every Client Access server in your on-premises organization. For details, see Configuring SSL Offloading in Exchange 2013
Although there are both private (internal network) and public (external network) settings to control attachments using Outlook Web App mailbox policies, admins require more consistent and reliable attachment handling when a user signs in to Outlook Web App from a computer on a public network such as at a coffee shop or library. Go here for details, Public Attachment Handling in Exchange Online.
Internet Explorer 10 and Windows Store apps using JavaScript support the Application Cache API (or AppCache), as defined in the HTML5 specification, which allows you to create offline web applications. AppCache enables webpages to cache (or save) resources locally, including images, script libraries, style sheets, and so on. In addition, AppCache allows URLs to be served from cached content using standard Uniform Resource Identifier (URI) notation. The following is a list of the browsers that support AppCache:
Internet Explorer 10 or later versions
Google Chrome 24 or later versions
Firefox 23 or later versions
Safari 6 or later (only on OS X/iOS) versions
Information workers in Exchange on-premises organizations need to collaborate with information workers in Exchange Online organizations when they are connected via an Exchange hybrid deployment. New in Exchange 2013 SP1, this connection can now be enabled and enhanced by using the new Exchange OAuth authentication protocol. The new Exchange OAuth authentication process will replace the Exchange federation trust configuration process and currently enables the following Exchange features:
Exchange hybrid deployment features, such as shared free/busy calendar information, MailTips, and Message Tracking.
Exchange In-place eDiscovery
For more information, see Configure OAuth Authentication Between Exchange and Exchange Online Organizations.
New in Exchange 2013 SP1, hybrid deployments are now supported in organizations with multiple Active Directory forests. For hybrid deployment features and considerations, multi-forest organizations are defined as organizations having Exchange servers deployed in multiple Active Directory forests. Organizations that utilize a resource forest for user accounts, but maintain all Exchange servers in a single forest, aren’t classified as multi-forest in hybrid deployment scenarios. These types of organizations should consider themselves a single forest organization when planning and configuring a hybrid deployment.
For more information, see Hybrid Deployments with Multiple Active Directory Forests.
Windows Server 2012 R2 enables you to create a failover cluster without an administrative access point. Exchange 2013 SP1 introduces the ability to leverage this capability and create a database availability group (DAG) without a cluster administrative access point. Creating a DAG without an administrative access point reduces complexity and simplifies DAG management. In addition, it reduces the attack surface of a DAG by removing the cluster/DAG name from DNS, thereby making it unresolvable over the network.
For more information, see High Availability and Site Resilience.
As with previous CUs, SP1 follows the new servicing paradigm that was previously discussed on the blog. This package can be used to perform a new installation, or to upgrade an existing Exchange Server 2013 installation to SP1. You do not need to install Cumulative Update 1 or 2 for Exchange Server 2013 RTM when you are installing SP1.
After you install this Service pack, you cannot uninstall the Service Pack to revert to an earlier version of Exchange 2013. If you uninstall this Service pack, Exchange 2013 is removed from the server.
Note that customised configuration files are overwritten on installation. Make sure you have any changes fully documented!
Once the Service Pack Installation has completed, restart the server. The server should be restarted even if you are not prompted.
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.
Cheers,
Rhoderick
Leading on where the previous post left off, here are the Exchange 2010 tips of the day from number 26 to 50.
For the related articles in this series please see:
Tips 1 – 25
Tips 51 – 75
Tips 76 - 101
Forget a property name? Not a problem because you can use wildcard characters to retrieve all properties that match the part of the name that you specify:
Get-Mailbox | Format-Table Name,*SMTP*
Want to work with data contained in a CSV file? Use Import-CSV to assign the data to an object. For example, type:
$MyCSV = Import-CSV TestFile.CSV
You can then manipulate the data easily in the Exchange Management Shell. For example, if there is a column called Mailboxes in the CSV data, you can use the following commands to sort or group the data by the Mailboxes column:
To sort: $MyCSV | Sort Mailboxes To group: $MyCSV | Group Mailboxes
This command spins through all your mailbox servers and reconnects all the uniquely identified but disconnected mailboxes in any one of the mailbox stores:
$Servers = Get-ExchangeServer $Servers | ` Where { $_.IsMailboxServer -Eq '$True' } ` | ForEach { Get-MailboxStatistics -Server $_.Name ` | Where { $_.DisconnectDate -NotLike '' } ` | ForEach { Connect-Mailbox -Identity ` $_.DisplayName -Database $_.DatabaseName} }
Tab completion reduces the number of keystrokes required to complete a cmdlet. Just press the TAB key to complete the cmdlet you are typing. Tab completion kicks in whenever there is a hyphen (-) in the input. For example:
Get-Send<tab>
should complete to Get-SendConnector. You can even use wildcards, such as:
Get-U*P*<tab>
Pressing the TAB key when you enter this command cycles through all cmdlets that match the expression, such as the Unified Messaging Mailbox policy cmdlets.
Want to create a group of test users in your lab? Use this command:
1..100 | ForEach { Net User "User$_" MyPassword=01 /ADD /Domain; Enable-Mailbox "User$_" }
Like the Exchange Management Shell Tip of the Day? Try this:
Get-Tip
Want to change the authentication settings on an Outlook Web Access virtual directory? Try the following command as an example. It changes authentication from forms-based authentication to Windows authentication:
Set-OwaVirtualDirectory -Identity "OWA (Default Web Site)" -FormsAuthentication 0 -WindowsAuthentication 1
Want to set the properties on all or some Outlook Web Access virtual directories? Pipe the output of Get-OwaVirtualDirectory to the Set-OwaVirtualDirectory cmdlet. For example, the following command sets the Gzip level for all Outlook Web Access virtual directories:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -GzipLevel High
Want to remove an ActiveSync device from a user's device list? Type:
Remove-ActiveSyncDevice
This cmdlet can be helpful for troubleshooting devices that don't synchronize successfully with the server.
Want to clear all data from a mobile device? Use:
Clear-ActiveSyncDevice
Specify a time of day to clear the device, or let the task complete the next time that the device connects to the server .
Want to see a list of all devices that synchronize with a user's mailbox? Type:
Get-ActiveSyncDeviceStatistics
A variety of information is returned including device name, operating system, and last sync time.
Has one of your users asked you to recover their mobile device synchronization password? To return the user's password, type:
Get-ActiveSyncDeviceStatistics -ShowRecoveryPassword
Want to move your database path to another location? Type:
Move-DatabasePath -EdbFilePath DestFileName
To change the file path setting without moving data, use this command together with the ConfigurationOnly parameter. This command is especially useful for disaster recovery. Caution: Misuse of this cmdlet will cause data loss.
Need an easy way to add a new primary SMTP address to a group of mailboxes? The following command creates a new e-mail address policy that assigns the @contoso.com domain to the primary SMTP address of all mailboxes with Contoso in the company field:
New-EmailAddressPolicy -Name Contoso -RecipientFilter {Company -Eq "Contoso"} -EnabledPrimarySMTPAddressTemplate "@contoso.com"
Want to retrieve a group of objects that have similar identities? You can use wildcard characters with the Identity parameter to match multiple objects. Type:
Get-Mailbox *John* Get-ReceiveConnector *toso.com Get-JournalRule *discovery*
Want to configure a group of objects that have similar identities? You can use wildcard characters with the Identity parameter when you use a Get cmdlet and pipe the output to a Set cmdlet. Type:
$Mailboxes = Get-Mailbox *John* $Mailboxes | Set-Mailbox -ProhibitSendQuota 100MB -UseDatabaseQuotaDefaults $False
This command matches all mailboxes with the name John in the mailbox's identity and sets the ProhibitSendQuota parameter to 100MB. It also sets the UseDatabaseQuotaDefaults parameter to $False so that the server uses the new quota you specified instead of the database default quota limits.
Forgot what the available parameters are on a cmdlet? Just use tab completion! Type:
Set-Mailbox -<tab>
When you type a hyphen (-) and then press the TAB key, you cycle through all the available parameters on the cmdlet. Want to narrow your search? Type part of the parameter's name and then press the TAB key. Type:
Set-Mailbox -Prohibit<tab>
Want to add an alias to multiple distribution groups that have a similar name? Type:
$Groups = Get-DistributionGroup *Exchange* $Groups | Add-DistributionGroupMember -Member kim
This command adds the alias kim to all distribution groups that contain the word Exchange.
Want to record exactly what happens when you're using the Exchange Management Shell? Use the Start-Transcript cmdlet. Anything that you do after you run this cmdlet will be recorded to a text file that you specify. To stop recording your session, use the Stop-Transcript cmdlet.
Notice that the Start-Transcript cmdlet overwrites the destination text file by default. If you want to append your session to an existing file, use the Append parameter:
Start-Transcript c:\MySession.txt -Append
Do you have a user who has network access but maintains an external mail account outside your Exchange organization? With Exchange Server 2010, you can now create mail-enabled users that are regular Active Directory accounts, but also behave like mail-enabled contacts. By using the Enable-MailUser cmdlet, you can add e-mail contact attributes to any existing Active Directory user who doesn't already have a mailbox on an Exchange server. Users in your Exchange organization will then be able to send e-mail messages to that user's external mail account. Type:
Enable-MailUser -Identity <Active Directory Alias> -ExternalEmailAddress <Destination SMTP Address>
Want to change the default prohibit send quota for a mailbox database? Type:
Set-MailboxDatabase <Mailbox Database Name> -ProhibitSendQuota <New Quota Size> -UseDatabaseQuotaDefaults $False
You can specify a bytes qualifier when you use the ProhibitSendQuota parameter. For example, if you want to set the prohibit send quota to 200 megabytes, type:
Set-MailboxDatabase <Mailbox Database Name> ProhibitSendQuota 200MB -UseDatabaseQuotaDefaults $False
You can also configure the IssueWarningQuota parameter and the ProhibitSendReceiveQuota parameter in the same way.
Want to know what version of Exchange Server each of your servers is running? Type:
Get-ExchangeServer | Format-Table Name, *Version*
Scanning Exchange databases with file system antivirus is a recipe for disaster. This really should not come as a surprise for admins running Exchange services within the enterprise, since this has been the field requirement for a long time. The documentation provided by Microsoft is very clear in what exclusions are required for file system antivirus and Exchange to coexist. For reference the relevant articles are:
If this is so well documented, then what could possibly go wrong? Plenty….
Update 30-6-2014: Please also see this post on a related issue.
Every vendor who writes a file system AV product will implement theirs in a different way. Because of this, and the fact that I will not identify vendors by name, this article will be written in a generic style. The concepts however will apply to the vast majority of AV products.
TechNet does a good job of listing the types of file system antivirus scanners:
Other terminology that may be encountered is the term On-Access. This is where AV will process a file when it is accessed. Unlike the On-Demand scan, if a file is never opened then it is never scanned. Reversely if it is opened multiple times then it will likely get scanned each time it is accessed. The exact details of this are at the discretion of the AV vendor.
The heuristics contained within each AV product vary greatly, and they behave differently on the above point and many others. Some do not show the configured file system exclusions in their admin tool graphical interface and you have to look at the registry to see what file system paths are actually being excluded. Others allow the AV team to lock the management application on the Exchange server down so that it is harder/impossible to see what scans are running, to troubleshoot issues and to terminate the AV scan (if required) without waiting for AV team to respond.
Please consult with your AV team and review their vendor’s documentation to understand how their product works .
Regrettably there are multiple issues that can and will arise if you allow file system AV to scan Exchange. Note that this is not just the mailbox database file, there are range of other locations that must also be exempted from file system AV scanning. For details see the links at the start of this post.
File-level scanners may scan a file when the file is being used or at a scheduled interval. This can cause the scanners to lock or quarantine an Exchange log file or a database file while Exchange tries to use the file. This behaviour may cause a severe failure in Microsoft Exchange and may also cause -1018 ESE errors.
One thing to note is that file-level scanners do not provide protection against e-mail viruses, such as the Storm Worm. Storm Worm was a backdoor Trojan horse virus that propagated itself through e-mail messages. The worm joined the infected computer to a botnet, where the computer was used to send spam e-mail messages in periodic bursts. Such viruses can affect the performance of the computer and the network that it is attached to.
This is not a new issue. As my friend Dave McGarr puts it over on his blog, Friends don’t let friends scan the M- drive ! Because of this, the M:\ drive was hidden by default in Exchange 2003. Exchange 2000, which introduced the M:\ Drive, was often negatively impacted by file system AV scanning M:\…..
This is the story of a recent engagement where I ran into some serious AV issues. The customer in question had recently completed an Exchange Server Risk Assessment (ExRAP). ExRAP looks at both technical and process aspects of managing messaging services. One interview question specifically asks if the correct AV exclusions have been implemented. The customer stated that they were.
Fast forward 4 months. The customer’s stable Exchange environment started to exhibit strange behaviours all of a sudden. Issues included degraded database performance, database failover issues and very poor Outlook client response times. As part of initial troubleshooting Microsoft requested that the AV exclusions be checked to ensure that they are correct and were not causing any issues. Again they were stated as correct. Screen shots and remote assistance sessions showed that the settings were entered. So what was causing databases not to failover between DAG members?
Well it turns out that only half of the puzzle was validated. Unbeknown to the Exchange admins, the AV team had implemented a weekly On-Demand scan that started late Sunday evening and scanned every single file on the server. Yes that's right -- zero exclusions… It gets better! These scans were taking a very long time to complete, and in some cases the scan did not complete until Wednesday or Thursday!
The AV product in use has a feature where it will lock a file that looks suspicious for an un-specified amount of time. The lock duration is controlled by the AV engine and is entirely at its discretion. This is what caused the database failover issues. When trying to mount a database on a server, AV locked the Exchange database as it though that MBD01.edb was suspicious. Since the file was locked, Exchange was unable to gain access to the database and mount it. If enough time elapsed then AV would release the file and the database could be mounted. Reviewing traces corroborated this, as we would see Exchange starting to read the database but not progressing further.
Not only was this an unsupported act as far as Microsoft is concerned the impact to the customer was tremendous. Some of the issues experienced were:
Rather than just state that the required exclusions be implemented, I thought it would be more beneficial to discuss some of the areas which typically contribute to the above situation, and some resolutions.
All teams must be tightly aligned on how AV is deployed and configured. While server teams like Exchange do not need to know the exact details of implementing AV on the backend, they must understand how to communicate with the other teams effectively, more on this in a minute! For example how do the Exchange servers get the correct AV policy assigned? Is it based on server name, location in AD or are Exchange servers manually tagged with a policy? This sounds minor, but this knowledge is critical in understanding the impact of choosing a different server name or the steps required if reinstalling an Exchange server from scratch.
To assist with communicating effectively, all teams should communicate using the same terminology to minimise any potential misunderstandings. In the above example, the Exchange team understood an AV exclusion to apply to any and all AV scans. However the AV teams did not share this viewpoint, and their terminology was more granular.
There must be a detailed discussion on the configuration of the AV policies that are applied to the Exchange infrastructure. Some examples include:
The AV agent health must be monitored by the AV team to ensure that an agent does not “go native”, and ignore its configuration. The worst possible case here would be for an agent to revert back to its default configuration which typically means that there are no exclusions and all files and processes are scanned.
AV team must accept that Exchange requires certain file system exclusions to operate in a supported manner by Microsoft. This is a tendency for such AV teams to perceive a security risk by the fact that MDB01.edb is never scanned by file system AV. Their concern that NaughyFile.edb will be stored on the Exchange server needs to be tempered with:
The above are only a few points in a typical discussion on this topic. Please engage with a security consultant to fully discuss such issues, as each enterprise will have different business requirements which translate into the underlying technical configuration. Some customers track these activities through a security sign off or waiver process.
Finally, do not assume that since a previous version of Exchange ran in a given environment, the AV conversation can be skipped! Take the time to ensure that all teams are on the same page, and that the correct exclusions are applied. Exchange 2010 has different exclusions compared to Exchange 2003! Additionally there will likely have been staff changes over the years since older AV policies were defined so have this critical conversation to prevent a critical situation – aka a CritSit!
The Exchange team today announced the availability of Update Rollup 5 for Exchange Server 2010 Service Pack 3. RU5 is the latest rollup of customer fixes available for Exchange Server 2010. The release contains fixes for customer reported issues and previously released security bulletins.
The astute reader will note that I did not post about the release of Exchange 2010 SP3 RU4 since that was a security release and contained only the security update in addition to SP3 RU3.
Update: 17-3-2014 Please also see this article KB 2925273 Folder views are not updated when you arrange by categories in Outlook after you apply Exchange Server 2010 Service Pack 3 Update Rollup 3 or Update Rollup 4
Update: 28-5-2014 The above issue contained in 2925273 is now corrected in Exchange 2010 SP3 RU6.
Exchange 2010 SP3 RU5 is not considered a security release as it contains no new previously unreleased security bulletin, but does contain all previous fixes. Exchange 2010 SP3 RU4 did include a security fix, which is present in RU5.
This is build 14.03.0181.006 of Exchange 2010, and KB2917508 has the full details for the release.
2913413 RPC Client Access service crashes with an exception in Exchange Server 2010
2919513 Memory leak or memory corruption occurs in Exchange Server 2010
2892257 Email items are lost when you move items between shared folders by using EWS delegate access
Now, before we rush off to download and install this there are a couple of items to mention!
After publishing some recent articles on RBAC, there was some feedback that a primer on RBAC would also be welcomed. So here it is!
It is not Really Boring Access Control. RBAC = Role Based Access Control. As a concept it is not new, however Exchange 2010 was the first time that it has been natively supported in Exchange. That being said, we still had the concept of roles in Exchange 2007 and older versions.
For example in Exchange 2003 we had these roles:
In Exchange 2007 we had slightly more roles:
As you can see the concept or roles is not new to Exchange, but why this RBAC thing? What’s that all about?
RBAC has many advantages compared to the previous administration model. RBAC allows for:
Access to Exchange 2010/2013 is controlled via RBAC. RBAC determines who can do what to a given object. This applies to both administrators and end users. RBAC will perform the action requested by the user and this will be in the security context of the Exchange Trusted Subsystem (ETS) universal security group. This is a change from previous versions where the credentials of the requesting users were used to access the object and make the necessary changes. As a result previous auditing methodologies need to change, so that we now make use of the Exchange auditing capabilities. ETS is a highly privileged group which contains read and write permissions to all Exchange objects. Nothing else should be added to this group.
RBAC is assigned to administrators to let them perform the necessary tasks on servers, connectors and mailboxes. This is in the form of a Role Assignment. RBAC to end users is delivered as a Role Assignment Policy. They are very similar but are tailored to their respective purpose.
In previous versions when a person was added to the Exchange Organization Administrators or Exchange Full Administrators roles they had every capability in Exchange. This is not the case any more, so become accustomed to not having access to all keys of the kingdom. Now, all the keys can be granted – it’s just that you do not have them by default. Examples of permissions and capabilities that an Org Admin does not have out of the box in Exchange 2010 include:
There are three main points to consider when planning out RBAC -- Where, What and Who.
OK – there is also the glue (role assignment that binds them), but let’s not mess up a nice list!
This is covered in detail by the RBAC Triangle Of Power.
Cutting through the terminology can be beneficial for reviewing RBAC. One frequently heard comment is that the word “role” is overused. When you see the main cmdlets laid out, it’s not bad! These are the core components of RBAC:
I’ll let you browse through the above content at your pleasure!
The end user RBAC roles contain cmdlets related to managing a user’s own mailbox and is scoped as such. Administrator RBAC roles contain the necessary cmdlets to manage the messaging infrastructure. Examples of Management Roles are show below:
They are represented in Active Directory as universal security groups, stored in the Microsoft Exchange Security Groups OU:
The Management Role contains Management Role Entries, which are the individual cmdlets and their parameters that actually let you do tasks. To see the actual Management Role Entries use the Get-ManagementRoleEntry cmdlet. Note that the Management Role Entries are stored within the Management Role, and this is why the syntax looks like Get-ManagementRoleEntry “ManagementRoleName\*”
Other examples to retrieve Management Role Entries could be:
It is fairly simple to understand how the built-in roles map to administrator or end user RBAC as the built in end user roles are prefixed with “My”. Custom roles are not obliged to follow this nomenclature (though it does make life easier if they do). To be sure of a Role type examine its IsEndUserRole property. The first role shown below is for end user RBAC, and the second is for administrators or specialist roles.
You will encounter two types of Role Groups on your travels. When Exchange 2010 or 2013 is installed into an AD forest all the necessary installation steps are executed, one of which is to install a base RBAC platform. If you have a multi forest (Exchange resource forest) environment, since the installation is executed in one forest then there is no knowledge of RBAC in the other forest. If you want to administer Exchange as a user from the account forest then you will need to tell Exchange in the resource forest who gets what administrative permissions in the user forest. In other words you need to roll your own RBAC for the user forest, this is a task that you need to perform as it is not automatically done.
A one way trust is the minimum requirement so the relevant AD objects are visible, and the RBAC roles can be defined. When assigning the roles, RBAC points to a Universal security group in the other forest and a Linked Role Group is created.
You will see this if you look for the RoleGroupType. Standard denotes a regular RBAC RoleGroup in the same forest as Exchange. Linked indicates that this is a linked role group to a remote forest.
Get-RoleGroup "Organization Management" | select Name, RoleGroupType | Format-Table -AutoSize
As the name implies, Management Scope stipulates where a particular set of permissions will apply. This could be scoped to a:
To perform advanced RBAC tasks you will certainly want to get familiar with this concept of management scopes since scopes allow you to control where a particular permission will apply. An example of a couple of scopes in one of my labs:
To create the Executive management scope we could run:
New-ManagementScope -name "Executives" -RecipientRestrictionFilter {memberofgroup -eq "cn=Execs,ou=VIP,dc=contoso,dc=com"}
On a related note, note that in PowerShell the equals character “ = “ is not used to evaluate if values match. The equals operator is text based and is “ –eq “ with the not equals operator being “ –ne “.
There is a handy table on TechNet or you can open PowerShell and review the output of:
Get-Help about_Comparison_Operators | More
Note that there are different aspects to scope, and the reason that I want to mention this is around scoping where users can read. While it is possible to limit the write aspects for both configuration and user scopes, read is at the organisation level.
Some folks like the above triangle of power to represent RBAC, but I personally prefer this graphic to really illustrate the relationships of the RBAC building blocks.
It pulls together all the concepts from Management Role Entries, Role Assignments and Role Assignment Policies.
Please see the previous posts to see how to create a custom RBAC role and then assign it to a group:
Creating RBAC Role To Delegate Contact Management - This one shows an example of using the “Mail Recipient Creation” role to create a customised role.
Allow Users To Manage Distribution Groups Without Creating New Ones - This one shows an example of customising the RBAC role assigned to an end user, and is something that RBC has already implemented in production.
How To Add Or Remove Cmdlet Parameter From RBAC Management Role - illustrates the amazing precision that is possible within RBAC
In case you were wondering about the Wipe Only ActiveSync Role that is shown in a couple of examples, this is discussed in RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices.
* – Should trademark that!
Most of the time when working with RBAC in Exchange we are not using large scripts to create and manage roles. Generally we use one-liners to configure RBAC. So I thought it would be useful to post some of the ones that I find myself frequently using.
As always please add a comment, or hit me up on the contact page and tell me want topics you want to see added here!
Get-ManagementRole –Cmdlet Set-CASMailbox
Get-ManagementRoleEntry “*\Set-CASMailbox
Get-ManagementRole –Parameter <parameter name>
Get-ManageMentRoleEntry “*\*” –parameter <parameter name>
This example works, but also review the next one down
Get-ManagementRole "Monitoring" | Select Name, RoleEntries | FL
Much better to use
Get-ManagementRoleEntry "Monitoring\*"
This can also be filtered. For example show me all the Get- cmdlets in the Mail Recipients role:
Get-ManagementRoleentry "Mail Recipients\Get-*"
Show me all the Set- cmdlets in the Mail Recipients role:
Get-ManagementRoleentry "Mail Recipients\Set-*"
Get-ManagementRoleAssignment -RoleAssigneeType User
Get-ManagementRoleAssignment –RoleAssigneeType RoleAssignmentPolicy
RoleAssignmentPolicy
Get-ManagementRoleAssignment -RoleAssigneeType RoleGroup
Get-RoleGroupMember -Identity "Organization Management"
Or
Get-RoleGroup -Identity "Organization Management" | Get-RoleGroupMember
The RoleAssignee parameter specifies the role group, assignment policy, user, or universal security group (USG) for which you want to view role assignments. If the RoleAssignee parameter is used, you can't use the Identity parameter.
By default, the command returns both direct role assignments to the role assignee, and indirect role assignments granted to a role assignee through role groups or assignment policies.
Get-ManagementRoleAssignment -RoleAssignee “Help Desk” | select Role,AssignmentMethod, EffectiveUserName
Using the Get-ManagementRoleAssignment cmdlet’s GetEffectiveUsers parameter, we can examine the effective permissions one individual has over another object. Using role groups and assignment policies make it easy to grant permissions to large numbers of users, you may not be aware of exactly who is a member of a role group, or who has been assigned an assignment policy. This is where the GetEffectiveUsers switch on the Get-ManagementRoleAssignment cmdlet is useful. It shows you what users are granted the permissions given by a management role through the role groups, assignment policies, and USGs that are assigned to them.
The GetEffectiveUser switch doesn't list users that are members of a linked foreign role group.
The GetEffectiveUsers switch specifies that the command should show the list of users in the role groups, assignment policies, or USGs associated with a role assignment. The users are effectively assigned the role assignment through their role group, assignment policy, or USG.
Show users that are granted permissions provided by the Mail Recipients role:
Get-ManagementRoleAssignment -Role "Mail Recipients" –GetEffectiveUsers
To find a specific user that's been granted permissions by a management role, you must use the Get-ManagementRoleAssignment cmdlet to retrieve a list of all effective users, and then pipe the output of the cmdlet to the Where cmdlet. The Where cmdlet filters the output and returns only the user you specified:
Get-ManagementRoleAssignment -Role Journaling -GetEffectiveUsers | Where { $_.EffectiveUserName -Eq "Matt Goss" }
To know every role that a user receives permissions from, you must use the Get-ManagementRoleAssignment cmdlet to retrieve all effective users on all management roles and then pipe the output of the cmdlet to the Where cmdlet. The Where cmdlet filters the output and returns only the role assignments that grant the user permissions.
Get-ManagementRoleAssignment -GetEffectiveUsers | Where { $_.EffectiveUserName -Eq "Ross Smith" }
In addition to the GetEffectiveusers option this is another one which is very useful – WritableReipient.
The WritableRecipient parameter specifies the recipient object you want to test to determine which role assignments allow it to be modified. The command takes into account the roles and scopes associated with each role assignment.
If this parameter is used with the GetEffectiveUsers switch, all of the users who can modify the recipient object indirectly through role groups and USGs are also returned. Without the GetEffectiveUsers switch, only the role groups, users, and USGs directly assigned the role assignment are returned.
In this example what can the Help-Desk-Admin do to account User-20?
Get-ManagementRoleAssignment -WritableRecipient User-20 -GetEffectiveUsers | where {$_.EffectiveUserName -eq "Help-Desk-Admin"}
In this example what can User-1 do to the MailContact object called Contact1 that is stored in AD?
Get-ManagementRoleAssignment -WritableRecipient Contact1 -GetEffectiveUsers | where {$_.EffectiveUserName -eq "user-1"}
Get-ManagementRoleAssignment provides a lot of filtering capabilities. You can customise this to tune searches to RoleAssignments that are Delegating, exclusive or by RoleAssigneeType.
While Exchange does not provide an out of the box mechanism to immediately show all RBAC in a single window (more on that in a future post), it does allow us to use the above PowerShell methods to create scripts and one-liners to discover and document. There are several example scripts out on ze interwebs, one example being here on MSPFE.
Get-ManagementRoleAssignment –GetEffectiveUsers | Where {$_.Enabled -eq $True} | Select-Object Role, RoleAssigneeName, RoleAssigneeType, RoleAssignmentDelegationtype, User, CustomRecipientWriteScope, CustomConfigWriteScope, RecipientWriteScope, ConfigWriteScope, Identity | Export-CSV $PWD\RBAC-Effective.csv -NoTypeInformation
Note that I changed the original example from MSPFE. Formatting was updated, .csv file path is no longer hardcoded and NoTypeInformation was added.
>>>
When designing an upgrade strategy from an older version of Exchange to a newer one, a question that needs to be addressed is do we need to introduce a version of Exchange that may not currently be present? This may be when upgrading from Exchange 2003 to Exchange 2010. If that organisation does not have any Exchange 2007 servers, you need to evaluate if there may be a future requirement for one in the future. Examples include:
Once that first Exchange 2010 server is installed it is way to late to go back and introduce Exchange 2007. Actually its before the installation, but hold that thought for now. The same is also true when upgrading from Exchange 2007 to Exchange 2013, if there are no Exchange 2010 servers in the organisation.
Let’s look at an example where we are upgrading from Exchange 2007 to Exchange 2013.
As mentioned above, it is not the act of installing the files onto the disk of the new Exchange 2013 server that blocks the installation of Exchange. Nor is it the act of extending the schema to support Exchange 20103. To be specific it is the /PrepareAD stage that is the critical point. This means once you’ve run Exchange 2013’s /PrepareAD command you cannot introduce a 2010 role if it did not exist before 2013’s /PrepareAD was executed.
The individual steps to manually prepare the AD infrastructure for Exchange are listed in the Prepare Active Directory and Domains documentation for Exchange 2007, Exchange 2010 and also Exchange 2013:
/PrepareAD prepares the local domain for Exchange.
Exchange 2013 does not have the /PrepareLegacy or /PL switch. This was required for legacy Exchange 2003 coexistence so the Recipient Update Service (RUS) could continue to function. Since Exchange 2013 has a hard requirement that Exchange 2003 has been removed from the organisation prior to starting its setup, this is no longer required. Thankfully that also means I don’t have to describe the public and private property sets in AD!
NOTE: If you run the Exchange Setup wizard with an account that has the permissions required (Schema Admins, Domain Admins, and Enterprise Admins) to prepare Active Directory and the domain, the wizard will automatically prepare Active Directory and the domain.
You say this would never happen? Let me give you the following scenario. Assume you get a shiny new administrator workstation that has the latest version of Windows installed. In order to install the Exchange management tools you need to install the management tools from the latest build of Exchange. If you then logon with a domain admin/schema admin level of account to install the management tools, setup will check the AD versioning information and run the /PrepareSchema, /PrepareAD steps.
Morale of the story? You should not need schema admin permissions for your day to day role, even for highly trusted administrator. Grant and revoke schema admin membership as needed. Less is more!
Running Exchange 2013 setup checks the current status of Active Directory and the Exchange organisation. Besides warning that some infrastructure bits are missing, it does warn that if you continue with this course of action, you will be unable to introduce older versions of Exchange if they are not currently present:
To enhance search engine effectiveness, the above text is also pasted here:
Error:This computer requires the Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit. Please install the software from http://go.microsoft.com/fwlink/?LinkId=260990.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.UcmaRedistMsi.aspx
Warning:Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE12ServerWarning.aspx
Warning:Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE14ServerWarning.aspx
Warning:This computer requires the Microsoft Office 2010 Filter Packs - Version 2.0. Please install the software from http://go.microsoft.com/fwlink/?LinkID=191548.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.MSFilterPackV2NotInstalled.aspx
Warning:This computer requires the Microsoft Office 2010 Filter Packs - Version 2.0 - Service Pack 1. Please install the software from http://go.microsoft.com/fwlink/?LinkId=262358.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.MSFilterPackV2SP1NotInstalled.aspx
Stop! Hammer time!
What if I want to retain the ability to install an older version of Exchange, what do I need to do?
Taking the previous example where we are upgrading from Exchange 2007 to Exchange 2013, and there are no Exchange 2010 servers in the organisation, what do we have to do to retain the ability to add more Exchange 2010 servers at a future date?
The simplest solution is to deploy a virtual machine, install Exchange 2010 with all of the roles (yes that is required if you want to be able to install all 2010 roles in the future), and keep it patched and running. Should you ever need to install a production Exchange 2010 server, since there is still one Exchange 2010 in the organisation you are able to do so. Note this did say all the roles that you want in the future. Installing just the Exchange 2010 Mailbox role is not sufficient…
Should you reach the point where there are no business requirements for Exchange 2010, Exchange can then be gracefully uninstalled from the virtual machine and life continues
The same rules applied when upgrading Exchange 2003 to Exchange 2010 where there are no Exchange 2007 servers in that organisation. If an Exchange 2007 server was not introduced prior to Exchange 2010, then you were unable to go back and add it later.
The Exchange Management Shell helps us discover the amazing capabilities of PowerShell. One way it does this is by displaying a tip of the day so that we are introduced to concepts and topics that inevitably will come in handy one day!
Since I had not see a complete list of the Exchange 2010 ones, I thought I’d jot them down. Exchange 2007 Tips are listed on TechNet.
Scroll down to the bottom for the PowerShell code used to retrieve this. And yes, the first four tips really are duplicated, though since they are randomly displayed it goes un-noticed! They remind me of a line from Red Dwarf *.
Tips 26 – 50
Did you know that the Identity parameter is a "positional parameter"? That means you can use:
Get-Mailbox "user" instead of: Get-Mailbox -Identity "user"
It's a neat usability shortcut!
Tired of typing a long command every time that you want to do something? Alias it! Type:
Set-Alias GetMre Get-ManagementRoleEntry
For all the current aliases, type:
Get-Alias
Want to see the members of a dynamic distribution group that has a custom filter? Just use the Get-Recipient cmdlet. Type:
$DDG = Get-DynamicDistributionGroup "Contoso Marketing Managers" Get-Recipient -RecipientPreviewFilter $DDG.RecipientFilter
The Exchange Management Shell is a calculator too! Try it directly at a command prompt:
1.2343+3123 or (23/435)*2
Command line SOS! Do you need help? Type:
Help <cmdlet-name> or <cmdlet-name> -?
You can choose what information to return when you view Help by using the Detailed, Full, and Examples switches:
Help Get-Mailbox -Detailed
Want to look at Help for a cmdlet but don't want to read through pages and pages of text in the Shell window? Just use the Online switch with the Get-Help cmdlet. The Online switch tells the Shell to open the online version of the cmdlet's Help topic in your default browser. Type:
Get-Help <cmdlet> -Online
The tilde character (~) should be familiar to Unix users. It represents the shortcut to your root directory. To see what it's evaluated to by default, type:
Dir ~
You can use it as a useful shortcut:
Cp SomeFile "~\My Documents"
CTRL+C is the equivalent of the hard-break command in the Exchange Management Shell. If a command is taking too long to run or you want to cancel an operation quickly, press CTRL+C to stop execution.
Tip of the day #12:
Pushd and Popd work the same way in the Exchange Management Shell as they do in cmd.exe. Type:
Pushd <location>
XML over everything! The Exchange Management Shell treats XML as a native type, so that you can do interesting things like:
$Sample = [XML](Get-Content SomeXMLFile.xml)
This command assigns $Sample to the actual XML object. To see it, type:
$Sample
To navigate, type:
$Sample.Prop1.Prop2
No need for text parsing when you want to load XML data!
Cmdlets that end in "Config" manage singleton configuration, either one per server or organization. For these tasks, you don't have to specify an identity because there is only one instance of the configuration. You may have to specify the Server parameter if the configuration is per server.
To get a list of all users on an Exchange 2010 server who aren't Unified Messaging-enabled, type:
$Mailboxes = Get-Mailbox $Mailboxes | ForEach { If($_.UmEnabled -Eq $False){$_.Name}}
To get a list of all users on an Exchange 2010 server who are Unified Messaging-enabled, type:
$Mailboxes = Get-Mailbox $Mailboxes = | ForEach { If($_.UmEnabled -Eq $True){$_.Name}}
To display the user's alias formatted in a table together with the user's Exchange 2010 server name and telephone extension, type:
Get-Mailbox | Format-Table ServerName,@{e={$_.SamAccountName};Label="User Alias"},@{Expression="Extensions";Label="Telephone numbers"}
To display the list of UM IP gateway server names disabled for outbound calling and hunt groups associated with a UM IP gateway server, type:
$Gateways = Get-UMIPGateway $Gateways | ForEach {If($_.OutCallsAllowed -Eq $False){ "Gateway Name = " +$_.Name;ForEach ($HuntGroup In $_.Huntgroups ){"Huntgroups " + $Huntgroup}}}
If you want to test all IP Block List providers, you just have to pipe the Get-IpBlockListProvider cmdlet to the Test-Ip BlockListProvider cmdlet:
Get-IpBlockListProvider | Test-IpBlockListProvider -IpAddress 192.168.0.1
Before you remove an object by using the Remove verb, use the WhatIf parameter to verify the results are what you expect.
Sometimes it's useful to convert the output of a cmdlet to a string to interoperate with native cmdlets. For example, type:
Get-Mailbox | Out-String | Findstr "Administrator"
Get all Win32 WMI information, such as Perfmon counters and local computer configurations. For example, type:
Get-WMIObject Win32_PerfRawData_PerfOS_Memory
Who isn't tired of spam? You can configure real-time block list (RBL) providers with the Exchange Management Shell by running the following two commands:
Set-IPBlockListProvidersConfig -Enabled $True -ExternalMailEnabled $True
and then
Add-IPBlockListProvider -Name <Name of RBL Provider> -LookupDomain <FQDN of RBL Provider> -AnyMatch $True
Access the event log from the Exchange Management Shell. To retrieve the whole event log, type:
Get-EventLog Application | Format-List
To retrieve all Exchange-related events, type:
Get-EventLog Application | Where { $_.Source -Ilike "*Exchange*" }
One benefit of the Exchange Management Shell is that cmdlets can output objects to the console. You can then manipulate this output and organize it in interesting ways. For example, to get a quick view in tabular format, use Format-Table:
Get-Mailbox | Format-Table Name,Database,RulesQuota
When the Exchange Management Shell shortcut is launched it does many things. The properties of the shortcut show the following:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"
RemoteExchange.ps1 calls another script --– CommonConnectFunctions.ps1. It is the latter script that creates the Get-Tip function which is called along with others to display the banner in the Exchange Management Shell.
For more details on the Exchange Management Shell please review this post.
Rather than go through and retrieve the tips one by one, PowerShell to the rescue! You can either use option 1 and save this to a .ps1 script or option two and just run as a oneliner.
Save the below to a .ps1 file and execute it in the Exchange Management Shell. Uses a While loop to iterate through all of the tips.
# Initialise the counter with a value of 1. $Int = 1 # PowerShell While Loop. Iterate to a count of 105 just to show that we have returned all tips While ($Int -le 105 ) { Get-Tip $Int Write-Host # Increment the counter $Int +=1 }
# Initialise the counter with a value of 1. $Int = 1
# PowerShell While Loop. Iterate to a count of 105 just to show that we have returned all tips While ($Int -le 105 ) { Get-Tip $Int Write-Host # Increment the counter $Int +=1 }
If you would like to just cut and paste, without reading any comments in the above go ahead and run this:
$Int = 1;While ($Int -le 105){Get-Tip $Int; Write-Host; $Int+=1}
The above PowerShell code will show all of the daily tips. To save your scroll finger from total exhaustion, the tips are split into 4 separate posts.
* - A superlative suggestion, sir, with just two minor flaws.
One: we don't have any defensive shields. And two: we don't have any defensive shields.
Now I realise that, technically speaking, that's only one flaw; but I thought it was such a big one, it was worth mentioning twice.
Here are the Exchange 2010 tips of the day from number 51 to 75.
Tips 1 - 25
Want to determine whether a server is running Exchange Server 2010 Standard Edition or Exchange Server 2010 Enterprise Edition? Type:
Get-ExchangeServer <Server Name> | Format-Table Name, Edition
If you want to view which edition all your Exchange servers are running, omit the <Server Name> parameter.
Want to create a new resource mailbox that can be used to book a meeting room? Type:
New-Mailbox -Name <Conference Room Name> -UserPrincipalName <SMTP Address> -OrganizationalUnit <Organizational Unit> -Room
This command creates a disabled Active Directory user who has a mailbox that accepts meeting requests from users.
Want to control the properties of e-mail messages sent to a specific domain? Use the RemoteDomain cmdlets. Create a new remote domain by using the New-RemoteDomain cmdlet. Type:
New-RemoteDomain -Name "Contoso.com Configuration" -DomainName contoso.com
Then modify the properties that you want for this remote domain by using the Set-RemoteDomain cmdlet:
Set-RemoteDomain "Contoso.com Configuration" -AutoReplyEnabled $True -AutoForwardEnabled $True
You can control which features are available to Outlook Web Access users by using the Set-OwaVirtualDirectory cmdlet. Type:
Set-OwaVirtualDirectory "OWA (Default Web Site)" -ContactsEnabled $True -ChangePasswordEnabled $True
Booleans are parameters that can be evaluated as either $True or $False. Booleans are typically used as a flag on an object that modifies the behavior of that object. In the Exchange Management Shell, you must supply a Boolean parameter with either a $True, $False, 1, or 0. No other values are accepted, including True or False. For example, both of the following commands set the enabled state of the ExampleAssignment management role assignment to $True:
Set-ManagementRoleAssignment ExampleAssignment -Enabled $True Set-ManagementRoleAssignment ExampleAssignment -Enabled 1
Want an easy way to apply deleted item retention limits across multiple databases and servers? Try the following command to configure deleted item retention across all databases on a specified server:
Get-MailboxDatabase -Server <Server Name> | Set-MailboxDatabase -DeletedItemRetention 45.00:00:00
You can also apply the same deleted item retention limits or mailbox retention limits across all servers in your organization:
Get-MailboxDatabase | Set-MailboxDatabase -DeletedItemRetention 45.00:00:00 -MailboxRetention 120.00:00:00
Want to know what permissions an Active Directory user account has on a specific mailbox? Use:
Get-Mailbox <Mailbox to Check> | Get-MailboxPermission -User <Active Directory User>
Want to know which mailboxes a specific Active Directory user has permissions to? Type:
$Mailboxes = Get-Mailbox -ResultSize Unlimited $Mailboxes | Get-MailboxPermission -User <Active Directory User> | Format-Table Identity, AccessRights, Deny
Caution: This command enumerates all the mailboxes in your organization. If you have lots of mailboxes, you may want to target specific mailboxes.
Want to get a list of the backup status of all mailbox databases in your organization? Type:
Get-MailboxDatabase -Status | Format-Table Name, Server, *Backup*
How about just the mailbox databases on a specific server? Type:
$Databases = Get-MailboxDatabase -Server <Server Name> -Status $Databases | Format-Table Name, *Backup*
To retrieve the current status of an Exchange server or database, use the Status parameter. For example:
Get-ExchangeServer -Status | Format-List Get-MailboxDatabase -Server <Server Name> -Status | Format-List
Want to view the mounted status of all mailbox databases? Type:
Get-MailboxDatabase -Status | Format-Table Name, Server, Mounted
What's the difference between server-side filtering and client-side filtering? Server-side filtering is used with the recipient and queue cmdlets, which support the Filter parameter, because these cmdlets can return large result sets. The server filters the results by using the criteria you specify and then sends you the filtered results. Client-side filtering can be used with any cmdlet. The entire result set is sent to the client computer, which then filters the data and provides a filtered result set. Client-side filtering uses the Where-Object cmdlet, which can be shortened to Where.
With Exchange Server 2010 Unified Messaging, you can redirect unauthenticated callers to certain telephone extensions to an operator instead of to the extension that was dialed. To list users for whom Unified Messaging transfers unauthenticated callers to the operator, instead of to the user, type:
$Mailboxes = Get-UMMailbox $Mailboxes | Where-Object { $_.AllowUMCallsFromNonUsers -eq ` [Microsoft.Exchange.Data.Directory.Recipient.AllowUMCallsFromNonUsersFlags] "None" }
You can use client-side filtering to return only the data that you want to see or work with. The following example retrieves all Active Directory user accounts in the Engineering department and puts the results in a table with two columns, Name and Department. By using the ResultSize parameter, the Get-User cmdlet limits the result set to 2,000 users.
$Users = Get-User -ResultSize 2000 $Users | Where { $_.Department -Eq "Engineering" } | Format-Table Name, Department
The special variable $_ represents the objects being passed from one cmdlet to another cmdlet in the pipeline. The $_ variable is automatically initiated by the Shell and is bound to the current pipeline object. You can access the properties of the object assigned to the $_ variable as you would any other object. The following example shows how you can view the Name property of each mailbox object that is passed through the pipeline:
Get-Mailbox | ForEach { $_.Name }
You can import CSV files and treat them as objects by using the Import-Csv cmdlet. Each row in a CSV file becomes an element in an array, and each column becomes a property. You can assign the CSV file to a variable, or you can pipe its contents directly to another cmdlet. In the following example, there are three columns in the CSV file, Name, Alias, and EmailAddress, with several rows that the ForEach cmdlet will cycle through. The data in each row is used to create a new mail contact.
$CSV = Import-Csv $CSV | ForEach { New-MailContact -Name $_.Name -Alias $_.Alias -ExternalEmailAddress $_.EmailAddress -OrganizationalUnit Users }
Want to customize your Exchange Management Shell profile? Run the following command to determine the location of your Microsoft.PowerShell_profile.ps1 file:
$Profile
You may have to create the PSConfiguration folder and Microsoft.PowerShell_profile.ps1 file. After you've done that, you can add your favorite functions and aliases, which will be loaded every time that the Exchange Management Shell is opened.
Want to see everything that occurs when you run a command? Include the Verbose parameter with the command. This parameter instructs the Exchange Management Shell to display detailed information about each action that the server takes to complete the command. This information can be useful in troubleshooting.
Any cmdlet that accepts a size value lets you specify whether the integer value is in kilobytes (KB), megabytes (MB), gigabytes (GB), or terabytes (TB). For example:
Set-Mailbox "Kim Akers" -ProhibitSendQuota 200MB -UseDatabaseQuotaDefaults $False
Want to create a new role group for your administrators? Use the New-RoleGroup cmdlet. The New-RoleGroup cmdlet lets you add management roles and specify the members to add to the new role group. Those members will be granted the permissions provided by the management roles. Type:
New-RoleGroup <role group name> -Roles <role 1>, <role 2>, <role 3...> -Members <member 1>, <member 2>, <member3...>
Remember, role groups are used to grant permissions to groups of administrators or specialist end users who require special permissions. If you want to manage permissions for end users, use management role assignment policies.
Do you want to create a new management role assignment policy that's based on an existing policy, but you don't want to include all of the management roles? Use the Get-ManagementRoleAssignment cmdlet and pipe the results to the Where cmdlet. The Where cmdlet excludes any role assignments that contain the roles you specify. The remaining role assignments are piped to the New-ManagementRoleAssignment cmdlet. Type:
New-RoleAssignmentPolicy <new role assignment policy name> Get-ManagementRoleAssignment -RoleAssignee <old role assignment policy name> | Where { ($_.Role -NE "<role name 1>") -And ($_.Role -NE "<role name 1>") } | New-ManagementRoleAssignment -Policy <new role assignment policy name>
Then you can apply the new policy to a mailbox using the Set-Mailbox cmdlet:
Set-Mailbox <mailbox name> -RoleAssignmentPolicy <new role assignment policy name>
Do you want to remove a management role from a role group, role assignment policy, USG or user but don't know the name o f the management role assignment? Just find the role assignment with the Get-ManagementRoleAssignment cmdlet and pipe the results to the Remove-ManagementRoleAssignment cmdlet. Type:
Get-ManagementRoleAssignment -RoleAssignee <role assignee name> -Role <role name> | Remove-ManagementRoleAssignment
Exchange 2010 uses management role groups and management role assignment policies to manage permissions. Role groups enable you to grant permissions to groups of administrators and specialist end users. These are people who manage your organization or perform special tasks, like mailbox searches for compliance reasons. Role assignment policies enable you to grant permissions to your end users. These permissions include whether users can manage their own distribution groups, edit their own profile information, access voice mail, and more.