Exchange Management Shell: everything is possible!
Powershell as a Microsoft Exchange Server Administration Tool first appeared in the 2007 product version 5 years ago. Since then, its use in Exchange Server has only become wider, and the introduction of Powershell remoting has opened up completely new possibilities for administrators.
Sysadmins master this scripting language, but the position in which they are located is not at all the same. Someone has been migrating their server from 2003 to 2010 and for them Powershell is a real challenge. Administrators of 2007 and 2010, at a minimum, opened the Exchange Management Shell (EMS) and experimented with it. For example, in such routine tasks as collecting configuration information or changing mailbox properties. Some, after these attempts, run back to the comfort of the Exchange Management Console (EMC) .
Those who do not use it, or use it insufficiently, deprive themselves of the excellent opportunity to explore and use in practice the constantly growing world of scripts, performing tasks on their servers that were previously impossible to perform.
It's no secret that Powershell can significantly improve some aspects of server management by filling in the white spots left by Microsoft .
There are a lot of examples of using Powershell to perform extremely important tasks from the point of view of administration.
For example, when I previously worked in a large American provider, a serious problem was the high RPC Latency on CAS servers, which was caused by problems with certain versions of iOS. Checking the load of CAS servers by monitoring the number of active connections, determining the client used during the connection, exporting the necessary information and compiling html reports — all this was done on Powershell and provided tremendous help.
Powershell is probably not the easiest language. In Exchange Server 2010 SP1, there are more than five hundred cmdlets and it will take time to study them. Despite this, the benefits of using it in the future will definitely pay off.
In this article, I’ll look at some of the Exchange Management Shell’s use cases for the system administrator. I emphasize that the purpose of the article is not to highlight everything (yes it is impossible!), But to show that Powershell for us, Microsoft Exchange Server fans, is really everything.
')
When you have to administer a large Exchange organization (or hosting, for example), you often encounter the need to create reports / reports in a form suitable for further editing. Sometimes they may be required at the request of clients, more often for internal audit purposes. The Exchange Management Shell has the ability to create highly detailed reports, which is an undoubted benefit for administrators. There are more than enough cmdlets starting with Get- * in combination with Windows PowerShell and the Exchange Management Shell, which provides truly unlimited customization of reports. Standard export is performed either in .txt, or in the .csv format - both extremely convenient for any subsequent data manipulations.
As a rule, the Out-File cmdlet is used to export to a text or CSV file (for CSV, Export-CSV). Let's say we have a task to export to the text file a list of all the mailboxes of the organization, using the Name and WhenCreated columns to filter the result display:
It must be said that along with the “correct” Powershell cmdlet Out-File also operates the old-school -
Another typical Exchange administration scenario is the mass creation of users from a CSV file. It can be used when migrating users from another environment, merging companies or simply hiring new employees. For this scenario, using CSV files is typical. First you need to prepare a CSV file. If the administrator has a desire to facilitate the task of subsequent changes in user attributes, it is logical to foresee everything in advance. When migrating or moving users from an ActiveDirectory-based environment, exporting the necessary AD user attributes allows you to quickly create them in a new place in the new ActiveDirectory.
We export via get-user, select the necessary attributes and transfer the result to the CSV file.
Now we have a CSV file completely ready for the subsequent import. In most cases, such a set of information in the CSV file is enough:
Lastname, Firstname, Name, UserPrincipalName, Password
Our file, ready for import into ActiveDirectory, is imported there by such a command, changing the required variables for itself -
Entering $ $ set into $ –ResetPasswordOnNextLogon will force users to change their password when they first log into the system.
Using this method, you can create hundreds of mailboxes in minutes, saving time significantly. Similarly, Powershell allows you to work with mailing lists and contacts.
Sometime in my practice, I encountered an interesting (and extremely urgent!) Request from a user who required to remove from the mailboxes of all employees of the organization (more than 200) one letter with extremely sensitive information for the company that was sent to the general mailing list by an employee who had previously been dismissed .
The cmdlet below allows you to search through the boxes of the required account and remove the unwanted message. In the script below, for the example, the subject of the letter is set, the mailbox where we put the “bad” message and the target folder.
Compared to Exchange 2007, this operation is much more convenient in the latest version of Exchange Server. The updated Get-MailboxDatabase cmdlet allows you to get almost any information.
We get the databases with the name, server, mount status and size:
Exchange 2010 allows you to handle client access to mailboxes based on the version of the Outlook client and the method of access to the mailbox.
There are several possibilities to restrict access by various criteria. For example, we want to prevent connection via RPC over HTTPS -
Such a cmdlet will not allow a mailbox client to be configured in a non-cached mode -
Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookNonCachedMode $ true
And so we will not allow users to use Outlook versions older than 2003.
This is how you can get beautiful information on mailboxes from a given account and export it to Excel:
And so the information about the free space on the hard drives of the server you need:
Get-WmiObject -Class Win32_Logicaldisk -computername | select deviceid, volumename, freespace
The Exchange Management Shell has a sufficient number of cmdlets that system administrators can use to troubleshoot the most common problems that may arise during the production environment.
If you have problems with logging in, the Test-MapiConnectivity cmdlet will come to the rescue inbox, which can be used with various parameters.
Check the possibility of login to a specific database -
Or in a specific mailbox -
Or on a specific server -
Problems with RPC connections are diagnosed using the Test-OutlookConnectivity cmdlet. The main difference from the previous cmdlet is the need to specify the password of the user being tested.
Since the CAS server role in Exchange 2010 provides access on a large number of protocols, it is quite natural that the creators of Microsoft Exchange Server 2010 made sure that there was no shortage of necessary cmdlets:
Test-ActiveSyncConnectivity - tests the ActiveSync protocol;
Test-CalendarConnectivity - test availability of the calendar;
Test-EcpConnectivity - validation of the ECP virtual directory on the selected CAS server
Test-ImapConnectivity - check the status of the IMAP service and client connectivity using this protocol
Test-OutlookWebServices - validation of information provided to a user by the AutoDiscover service
Test-OwaConnectivity - validation of the OWA virtual directory on the specified CAS server
Test-WebServicesConnectivity - test Exchange Web Services, which are used, for example, Outlook for Mac, Mac Mail and some other clients.
These are just a few scenarios in which the Exchange Management Shell can be used, real work with it and work with Exchange 2010 open the doors to this world much wider. And the more the system administrator learns about him, the more he relies on him in his daily work - it's hard not to appreciate the amazing scripting and automation of operations that this language carries.
Sysadmins master this scripting language, but the position in which they are located is not at all the same. Someone has been migrating their server from 2003 to 2010 and for them Powershell is a real challenge. Administrators of 2007 and 2010, at a minimum, opened the Exchange Management Shell (EMS) and experimented with it. For example, in such routine tasks as collecting configuration information or changing mailbox properties. Some, after these attempts, run back to the comfort of the Exchange Management Console (EMC) .
Those who do not use it, or use it insufficiently, deprive themselves of the excellent opportunity to explore and use in practice the constantly growing world of scripts, performing tasks on their servers that were previously impossible to perform.
It's no secret that Powershell can significantly improve some aspects of server management by filling in the white spots left by Microsoft .
There are a lot of examples of using Powershell to perform extremely important tasks from the point of view of administration.
For example, when I previously worked in a large American provider, a serious problem was the high RPC Latency on CAS servers, which was caused by problems with certain versions of iOS. Checking the load of CAS servers by monitoring the number of active connections, determining the client used during the connection, exporting the necessary information and compiling html reports — all this was done on Powershell and provided tremendous help.
Powershell is probably not the easiest language. In Exchange Server 2010 SP1, there are more than five hundred cmdlets and it will take time to study them. Despite this, the benefits of using it in the future will definitely pay off.
In this article, I’ll look at some of the Exchange Management Shell’s use cases for the system administrator. I emphasize that the purpose of the article is not to highlight everything (yes it is impossible!), But to show that Powershell for us, Microsoft Exchange Server fans, is really everything.
1. Creating reports and exporting them
')
When you have to administer a large Exchange organization (or hosting, for example), you often encounter the need to create reports / reports in a form suitable for further editing. Sometimes they may be required at the request of clients, more often for internal audit purposes. The Exchange Management Shell has the ability to create highly detailed reports, which is an undoubted benefit for administrators. There are more than enough cmdlets starting with Get- * in combination with Windows PowerShell and the Exchange Management Shell, which provides truly unlimited customization of reports. Standard export is performed either in .txt, or in the .csv format - both extremely convenient for any subsequent data manipulations.
As a rule, the Out-File cmdlet is used to export to a text or CSV file (for CSV, Export-CSV). Let's say we have a task to export to the text file a list of all the mailboxes of the organization, using the Name and WhenCreated columns to filter the result display:
Get-Mailbox | Select-Object Name,WhenCreated | Out-File c:\xfer\report.txt
It must be said that along with the “correct” Powershell cmdlet Out-File also operates the old-school -
[PS] C:\Windows\system32>Get-Mailbox | Select-Object Name,WhenCreated > c:\xfer\report.txt
2. Mass creation of users from a CSV file
Another typical Exchange administration scenario is the mass creation of users from a CSV file. It can be used when migrating users from another environment, merging companies or simply hiring new employees. For this scenario, using CSV files is typical. First you need to prepare a CSV file. If the administrator has a desire to facilitate the task of subsequent changes in user attributes, it is logical to foresee everything in advance. When migrating or moving users from an ActiveDirectory-based environment, exporting the necessary AD user attributes allows you to quickly create them in a new place in the new ActiveDirectory.
We export via get-user, select the necessary attributes and transfer the result to the CSV file.
Now we have a CSV file completely ready for the subsequent import. In most cases, such a set of information in the CSV file is enough:
Lastname, Firstname, Name, UserPrincipalName, Password
Our file, ready for import into ActiveDirectory, is imported there by such a command, changing the required variables for itself -
Import-CSV c:\xfer\our_import.csv | ForEach-Object { New-Mailbox -Lastname $_.”LastName” -Name $_."Name" -FirstName $_.”FirstName” -Organization Our Organization -Database DB1 -UserPrincipalName $_.”UserPrincipalName” -Password (ConvertTo-SecureString $_.password -AsPlainText -Force)}
Entering $ $ set into $ –ResetPasswordOnNextLogon will force users to change their password when they first log into the system.
Using this method, you can create hundreds of mailboxes in minutes, saving time significantly. Similarly, Powershell allows you to work with mailing lists and contacts.
3. How to remove a “bad” message from all mailboxes at once?
Sometime in my practice, I encountered an interesting (and extremely urgent!) Request from a user who required to remove from the mailboxes of all employees of the organization (more than 200) one letter with extremely sensitive information for the company that was sent to the general mailing list by an employee who had previously been dismissed .
The cmdlet below allows you to search through the boxes of the required account and remove the unwanted message. In the script below, for the example, the subject of the letter is set, the mailbox where we put the “bad” message and the target folder.
get-mailbox -OrganizationalUnit Needed_OU -ResultSize unlimited | Search-Mailbox -SearchQuery Subject:'Very bad message' -TargetMailbox mailbox@mailbox.com -TargetFolder Inbox –DeleteContent
4. Check the size of the mail database
Compared to Exchange 2007, this operation is much more convenient in the latest version of Exchange Server. The updated Get-MailboxDatabase cmdlet allows you to get almost any information.
We get the databases with the name, server, mount status and size:
Get-MailboxDatabase -Status | select-object Name,Server,DatabaseSize,Mounted
5. Mail client and mailboxes
Exchange 2010 allows you to handle client access to mailboxes based on the version of the Outlook client and the method of access to the mailbox.
There are several possibilities to restrict access by various criteria. For example, we want to prevent connection via RPC over HTTPS -
Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookRpcHttp $true
Such a cmdlet will not allow a mailbox client to be configured in a non-cached mode -
Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookNonCachedMode $ true
And so we will not allow users to use Outlook versions older than 2003.
Get-CASMailbox -Resultsize Unlimited | Set-CASMailbox -MAPIBlockOutlookVersions '-5.9.9;7.0.0-10.9.9'
This is how you can get beautiful information on mailboxes from a given account and export it to Excel:
Get-Mailbox -OrganizationalUnit groza -Resultsize unlimited | Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | Select-Object DisplayName,@{Name="TotalItemSize(KB)";Expression={$_.TotalItemSize.Value.ToKB()}},ItemCount,lastlogontime,lastlogofftime,lastloggedonuseraccount | Export-Csv c:\xfer\groza.csv | foreach {$_.length=($_.length)/1024/1024/1024; $_}
And so the information about the free space on the hard drives of the server you need:
Get-WmiObject -Class Win32_Logicaldisk -computername | select deviceid, volumename, freespace
6. Client Access
The Exchange Management Shell has a sufficient number of cmdlets that system administrators can use to troubleshoot the most common problems that may arise during the production environment.
If you have problems with logging in, the Test-MapiConnectivity cmdlet will come to the rescue inbox, which can be used with various parameters.
Check the possibility of login to a specific database -
Test-MAPIConnectivity -Database DB1
Or in a specific mailbox -
Test-MAPIConnectivity –Identity Vorobyaninov@RK.downtime.ru
Or on a specific server -
Test-MAPIConnectivity -Server MBX1
Problems with RPC connections are diagnosed using the Test-OutlookConnectivity cmdlet. The main difference from the previous cmdlet is the need to specify the password of the user being tested.
Since the CAS server role in Exchange 2010 provides access on a large number of protocols, it is quite natural that the creators of Microsoft Exchange Server 2010 made sure that there was no shortage of necessary cmdlets:
Test-ActiveSyncConnectivity - tests the ActiveSync protocol;
Test-CalendarConnectivity - test availability of the calendar;
Test-EcpConnectivity - validation of the ECP virtual directory on the selected CAS server
Test-ImapConnectivity - check the status of the IMAP service and client connectivity using this protocol
Test-OutlookWebServices - validation of information provided to a user by the AutoDiscover service
Test-OwaConnectivity - validation of the OWA virtual directory on the specified CAS server
Test-WebServicesConnectivity - test Exchange Web Services, which are used, for example, Outlook for Mac, Mac Mail and some other clients.
These are just a few scenarios in which the Exchange Management Shell can be used, real work with it and work with Exchange 2010 open the doors to this world much wider. And the more the system administrator learns about him, the more he relies on him in his daily work - it's hard not to appreciate the amazing scripting and automation of operations that this language carries.
Source: https://habr.com/ru/post/130640/
All Articles