Check Exchange 2007 with PowerShell - Part 2

Check Exchange 2007 with PowerShell - Part 1

Neil Hobson

Network Administration - In part 1 of this two-part series, I talked about Exchange Management Shell commands starting with Test- which can be used to test the configuration and operation of machines. Exchange 2007 server. These commands can also be used to help resolve problems that occur after servers are placed into the production environment. In the first section, we learned about the Test-ServiceHealth and Test-OutlookWebServices commands. In this section, we will show you the Test-MAPIConnectivity, Test-ExchangeSearch, Test-OwaConnectivity, Test-WebServicesConnectivity, Test-PopConnectivity and Test-ImapConnectivity commands.

Test-MAPIConnectivity

Perhaps the most obvious connection method for a client is through MAPI, with this connection, there is a simple test done through the Test-MAPIConnectivity command. This command needs to log into a mailbox to test the functionality and so you can use the -Identity parameter to identify this target mailbox. That said, if you do not specify a specific mailbox, this command will log into the SystemMailbox found in each database.

You also need to specify the –Database parameter to distinguish the databases that you like to log into. If ignored, all databases on the internal server will be logged. As with many other commands, you can use the –Server parameter to control which server you like to test. The output you get from this command is shown in Figure 6. This command has no additional parameters provided, which means that both databases are logged on the mailbox server. internal. Notice the delay information provided, it shows you the delay during login to each mailbox.

Figure 6: Output of Test-MAPIConnectivity

If any problem occurs during the mailbox login process, the Result column will display the word * FAILURE * and the Error column will give you a detailed description of the error.

Test-ExchangeSearch

Some things related to checking the connectivity of mailboxes are checking the content indexing to function properly. The Test-ExchangeSearch command can be used for this process and will work by creating a message with an attachment, which can only be found through Exchange Search. Because indexing of content is enabled by default in Exchange 2007, you need to check the information promptly before putting the server into real use in a production environment. The structure of this command to use is simple:

Test-ExchangeSearch –Server

Figure 7 shows the result of executing this command in the absence of any additional parameters provided. As you can see, this command is looking for the SystemAttendant mailbox and is being searched on the internal mailbox server because no -Server parameter is provided.

Figure 7: Process of Test-ExchangeSearch command

At the end of the process, the results will be displayed and as you can see from Figure 8, there is an item found successfully in the 9s time period. One of the main parameters for this command is the –IndexingTimeout parameter, which controls the amount of time that the process will wait while searching for an item before returning an error message. The default setting of 120s will be a reasonable time for such a test. If you notice below this number, the command will start the search as shown in Figure 7 and, if this time is exceeded, the search will be stopped immediately and returned a screen The status image is shown in Figure 8, when the ResultFound column shows False and the SearchTime column represents a value of -1 .

Figure 8: Output of Test-ExchangeSearch command

Test-OwaConnectivity

Test-OwaConnectivity is a more complex command during use. The reason we say this is because there are more parameters that can be used with this command than the other commands introduced to you in this article. The main purpose, this command is used to check all OWA virtual directories on a Client Access Server or a URL. Let's take a look at an example of a URL. To test a URL, there are two main parameters to consider here. These parameters are –URL and –TestType. The –URL parameter specifies the OWA URL you want to check, while the –TestType parameter can be used to check the internal or external OWA URL. By default, the –TestType parameter checks the internal URL, but you can configure it to check the external URL by entering the parameter –TestType: External.

We need to consider the information that will be used to log in and check for OWA connectivity. This is done through the –MailboxCredential parameter , which will bring up an authentication window for you to enter your account information. One final parameter worth considering is –TrustAnySSLCertificate, which is useful when you check internal URLs because in these cases, it is typical for a valid certificate name with an external URL, not right URL inside. This parameter will effectively guarantee errors. Let's take a closer look in one case where we will examine the internal internal URL of an Exchange 2007 server named E2K7 using the administrator account information and any SSL certificates. any authentication. The command to be used is:

Test-OwaConnectivity -URL https: // E2K7 / owa -MailboxCredential (Get-Credential Listening Administrator) -TrustAnySSLCertificate

The output of the command is shown in Figure 9.

Figure 9: Output of Test-OwaConnectivity command

As with many of the other commands detailed in this article, you can see the process delay being displayed with an error or success. If we have chosen not to enforce the authentication of the SSL certificate and our certificate has a different name than the one used in the –URL parameter, then we will get a warning error below. :

'WARNING: Đã thử không thể đăng nhập vào Outlook Access Web vì SSL certificate không hợp lệ.'
'Warning: The test process cannot log into Outlook Web Access because the SSL certificate is invalid'

This is shown in Figure 10.

Figure 10: An error occurred when executing the Test-OwaConnectivity command

Test-WebServicesConnectivity

To test the functionality and configuration of Outlook Anywhere, you can use the Test-WebServicesConnectivity cmdlet . Like the Test-OwaConnectivity cmdlet, this command is also a complex command because many parameters can be used. However, at the basic level, the following command can be used to test Outlook Anywhere:

Test-WebServicesConnectivity –ClientAccessServer E2K7 –MailboxCredential (Get-Credential NGHadministrator)

You will see that we use the Get-Credential command to retrieve the name and password of the corresponding account, and in this case, we will communicate with a Client Access Server, which has the name E2K7. Figure 11 shows the results of running this command, you can see the different tests performed and the latency results corresponding to them.

Figure 11: Output of Test-WebServicesConnectivity command

This command is also very helpful in guiding you how to do this to resolve configuration issues. For example, see the output in Figure 12, where you see the error message listed that tells us there is a certificate configuration issue in the system.

Figure 12: Error message of Test-WebServicesConnectivity command

Test-PopConnectivity and Test-ImapConnectivity

These two commands are used to check the functionality of POP3 and IMAP4 services. Some of the main parameters used with these commands include –ClientAccessServer and –MailboxCredential to create a login via POP3 or IMAP4. For example, the following command will generate the results shown in Figure 13.

Test-PopConnectivity –ClientAccessServer E2K7 –MailboxCredential (Get-Credential NGHAdministrator)

Figure 13: An error occurred when executing the Test-PopConnectivity command

Here you can also see the results of the testing process as well as the latency. Looking at the Error column you will see a lot of useful things about what happens, because the POP3 service is disabled by default during the new Exchange 2007 installation. Therefore, to balance many things, this is What you need to consider for successful login.

Figure 14: Perform the Test-PopConnectivity command

In the previous part of this article, we saw how to use the –IndexingTimeout parameter with the Test-ExchangeSearch command to control the waiting period before deciding that items cannot be retrieved from the information store. . Both Test-PopConnectivity and Test-ImapConnectivity commands have the –Timeout parameter, which is set by default to 30s. You should check the other parameters that these test commands have.

MonitoringContext parameter

If you have looked at the parameters available with each Test command, you will see that a parameter is always listed as an option, this parameter is called MonitoringContext . It is used by the Exchange Management Pack for Systems Center Operations Manager (SCOM). What this parameter does is return the test events and performance counter parameters as well as the provided information you saw from the pictures in this article.

If you want to see this information appear at the output of the commands, simply use the MonitoringContext parameter. This is a simple Boolean parameter and so options can be only $ true or $ false . If this parameter is set to $ true, then you will receive additional information related to checking events and performance counting parameters. For example, Figure 15 shows the results of the Test-MAPIConnectivity command used in conjunction with the MonitoringContext parameter set to $ true. Note that the specific latency values ​​will get inside the PerformanceCounters section instead of the values ​​made as shown in Figure 6.

Figure 15: Output of Test-MAPIConnectivity command with MonitoringContext

Conclude

Over the two parts of this article, we have introduced you to various Test- commands that you can use to test the configuration and operation of Exchange 2007 servers. For the whole of this article, there are many parameters that can be used along with the commands, so you should refer to these commands more fully and remember to use them when checking your Exchange environment. me