• Home

Most Recent Posts

I mentioned this on Twitter a while back, but I find it worth posting again as they recently helped me in troubleshooting some issues with a customer. Just prior to RTM of Lync 2013, Microsoft released a new set of Debugging Tools. Included in the bundle are updated versions of Snooper, OCSLogger, OCSTracer, and ClsController.psm1.

A brief rundown of each tool and/or changes in the new release:

Snooper - Updated to include a SIP call flow ladder. This is incredibly useful when troubleshooting potential call issues. The great thing about this version of Snooper is that is can be used with legacy versions of Lync and OCS logs! See below for an example screenshot.



OCSLogger - Notable inclusion because OCSLogger is no longer installed with Lync 2013 as it has been in previous versions. This is primarily because of the new Centralized Logging Service (CLS).

OCSTracer - Used in conjunction with OCSLogger to capture and parse OCS/Lync logs. This is what converts the ETL logs captured by OCSLogger into “human readable” log files.

ClsController.psm1 - This PowerShell Module can be loaded on a Front End server to customize the CLS scenarios available out of the box to more closely scope them to fit your troubleshooting needs.

You can download the latest version of the Lync 2013 Debugging Tools here.

Happy Troubleshooting!

- Phil Sharp, Solution Architect
You can read more posts by Phil at Mastering Microsoft UC.

While reviewing the new PowerShell commands that were added with CU1 for Exchange Server 2013 RTM, it dawned on me that I had not looked to see what changes were made from Exchange 2010 SP2 to SP3. Apparently there were quite a few changes made. Here is what I have found:

PowerShell Cmdlets Removed

Get-MailboxExportRequest **
Get-MailboxExportRequestStatistics **
Get-MailboxImportRequest **
Get-MailboxImportRequestStatistics **
New-LinkedUser
New-MailboxExportRequest **
New-MailboxImportRequest **
Remove-LinkedUser
Remove-MailboxExportRequest **
Remove-MailboxImportRequest **
Resume-MailboxImportRequest
Search-Mailbox
Set-LinkedUser
Set-MailboxExportRequest **
Set-MailboxImportRequest **
Suspend-MailboxExportRequest **
Suspend-MailboxImportRequest **

** Ironically ‘Resume-MailboxExportRequest’ was left in SP3 even though all the other related commands were removed.

Here is a great write-up on this set of related commands.

To add even more to the confusion, these commands were supposedly added back to Exchange 2013 RTM according to this TechNet Article for New-MailboxExportRequest. I am unable to find these commands in Exchange 2013 RTM and RTM CU1.

What’s up with that?

One would assume that would mean that Exchange 2013 Preview would have the commands?

While researching each command, I noticed that each of the mailbox import/export commands mentioned that they should be in Exchange 2010 SP2 and SP3. However, none of these were in 2010 SP3. Here are my screenshots as evidence. I’ve included the article with the mention of SP3 circled as well as proof of Exchange version and that the command does not exits. Here they are:

As you can see from the above screenshots, I would just have to assume these updates did not make it to the documentation. Possibly the commands were eliminated for compatibility with Exchange 2013 RTM CU1?

Now on to the new PowerShell commands added to Exchange 2010 SP3.

PowerShell Cmdlets Added

Get-MailboxSearch
Get-MailboxSentItemsConfiguration
Get-MigrationBatch – No TechNet link for Exchange 2010, only 2013
Get-PublicFolderMoveRequest – No TechNet link for Exchange 2010, only 2013
Get-PublicFolderMoveRequestStatistics – No TechNet link for Exchange 2010, only 2013
Get-UMPhoneSession – No TechNet link for Exchange 2010, only 2013
New-AuthRedirect – According to Mike Crowley this is reserved for future use
New-MailboxSearch
New-MigrationBatch – No TechNet link for Exchange 2010, only 2013
New-PublicFolderMoveRequestNew-PublicFolderMoveRequest
Remove-AuthRedirect – According to Mike Crowley this is reserved for future use
Remove-MailboxSearch
Remove-PublicFolderMoveRequest – No TechNet link for Exchange 2010, only 2013
Resume-PublicFolderMoveRequest
Set-AuthRedirect – According to Mike Crowley this is reserved for future use
Set-MailboxSearch
Set-MailboxSentItemsConfiguration
Set-MigrationBatch – No TechNet link for Exchange 2010, only 2013
Set-PublicFolderMoveRequest – No TechNet link for Exchange 2010, only 2013
Start-MigrationBatch
Start-UMPhoneSession
Stop-MigrationBatch
Stop-UMPhoneSession
Suspend-PublicFolderMoveRequest
Test-MigrationServerAvailability

- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.

While researching PowerShell commands for an article I was writing (PowerShell commands added with SP3) I realized that two of my Exchange 2010 SP2 test labs were reporting different commands available for use. One lab was built a long time ago as an Exchange 2010 RTM server, eventually upgraded to SP1 and then to SP2 [SP3 will have to be done at another date]. The second lab was a straight Exchange 2010 SP2 build with no upgrades done over time. Since both of these labs are Service Pack 2, you would think that the available PowerShell commands would be exactly the same. They are not.

Lab 1 has these commands available to it – Lab1 PowerShell.
Lab 2 has these commands available to it – Lab2 PowerShell.

As you can see these lists are not equivalent. Lab 1 has an additional 19 commands that Lab 2 does not. These commands included:

• Get-LinkedUser
• Get-MailboxExportRequest
• Get-MailboxExportRequestStatistics
• Get-MailboxImportRequest
• Get-MailboxImportRequestStatistics
• Get-UMMailboxConfiguration
• New-LinkedUser
• New-MailboxExportRequest
• New-MailboxImportRequest
• Remove-LinkedUser
• Remove-MailboxExportRequest
• Remove-MailboxImportRequest
• Remove-PowerShellVirtualDirectory
• Resume-MailboxImportRequest
• Set-LinkedUser
• Set-MailboxExportRequest
• Set-MailboxImportRequest
• Suspend-MailboxExportRequest
• Suspend-MailboxImportRequest

The question is, why are they different? First, let’s look at the exsetup file to make sure these servers are the same install base:

Lab 1



Lab 2



Let’s also look to see what modules are loaded on the install for PowerShell in each lab:

Lab 1


Lab 2



In our case we only have one module that is loaded in both lab environments.

Where is Exchange pulling these command lists from then? Well, there are a couple of reference files for PowerShell. These files are as follows:



XML File – The Format.ps1xml files in Windows PowerShell define the default display of objects in the Windows PowerShell console. You can create your own Format.ps1xml files to change the display of objects or to define default displays for new object types that you create in Windows PowerShell. [Source]

.Psd1 – A module manifest is a .psd1 file that contains a hash table. The keys and values in the hash table:
* Describe the contents and attributes of the module.
* Define the prerequisites.
* Determine how the components are processed.
[Source]

.Psm1 – A script module is a file (.psm1) that contains any valid Windows PowerShell code. Script developers and administrators can use this type of module to create modules whose members include functions, variables, and more.
[Source]

OK. So what are the differences in these files between lab 1 and lab 2?

I ran a check of the files via this link – http://www.diffchecker.com/diff

The .XML files showed no difference at all.
The same was found on the .PSD1 files.
However, in the .PSM1 files there are numerous things that are indeed different:

The above screenshots are not comprehensive of the changes that can be found in these files. Even with the above information, we are no closer to finding an answer to the ‘Why’ question I raised at the very top of this post. I am still investigating the issue, but I have not been able to find any more a definitive answer than timing. I applied SP2 for Exchange 2010 in Lab 1 when it first came out and in April 2013 for Lab 2. Does this mean that SP2 files have changed over time? I don’t know as I am still looking for my original SP2 for Lab 1.

If anyone has any knowledge on this please drop a comment. Thanks.

- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.

Microsoft has again added new scripts to the Scripts directory for Exchange. This time we have 4 new scripts with the release of CU1.


New Scripts

• Disable-OutsideIn.ps1
• Enable-OutsideIn.ps1
• FilteringConfigurationCommands.ps1
• ManagedStoreDiagnosticFunctions.ps1

Here is what each script does:

Disable-OutsideIn.ps1 – The Disable-OutsideIn script disables Oracle Outside In Technology (c) for text extraction.
Enable-OutsideIn.ps1 – The Enable-OutsideIn script enables Oracle Outside In Technology (c) for text extraction.
FilteringConfigurationCommands.ps1 – Finds and backs up the FIPS configuration file, Returns the full path to the FIPS configuration file, Returns null on failure
ManagedStoreDiagnosticFunctions.ps1 – Run a query against a managed store mailbox database

Resources
Oracle Outside In Technology
FIPS compliance information
Managed Mailbox Databases

- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.

For part 3 of this series we’ll look at the Exchange Administrators Console (EAC). While the changes here are not extensive, I believe most of the changes will make for a better experience using EAC to manage your environment.

Let’s just dive into the changes in the console:

Recipients – Mailboxes
From the screenshots below, you can see that there is a change to the drop down when you click on the ‘…’ button.

Exchange 2013 RTM


Exchange 2013 RTM CU1

Now if you’ve used the RTM version of Exchange 2013, you will notice that the Disable mailbox option has been moved to the ‘…’ button instead of being a drop down off the Trash can icon. My guess is that this was done for ease of use and to prevent people from accidentally deleting mailboxes when all they want to do is disable a mailbox.


Recipients – Groups
The change to the options or ‘…’ menu are merely cosmetic on this tab.

Exchange 2013 RTM


Exchange 2013 RTM CU1



Recipients – Resources
The change to the options or ‘…’ menu are also cosmetic on this tab.

Exchange 2013 RTM


Exchange 2013 RTM CU1



Recipients – Resources
The change to the options or ‘…’ menu are again cosmetic on this tab.

Exchange 2013 RTM


Exchange 2013 RTM CU1



Permissions – Outlook Web App
when configuring a new OWA policy a couple of options under Information Management have been removed from the RTM version of the policies. Specifically Search Folders and Public Folders.

Exchange 2013 RTM


Exchange 2013 RTM CU1



Compliance Management – Auditing
If you were to run a new Admin Role Group report in CU1, you would notice that the screen is organized a bit different than it was in the RTM version of Exchange. Now the date range is logically put at the top and the search results are at the bottom.


Exchange 2013 RTM


Exchange 2013 RTM CU1



Protection – Malware Filter
The Malware Filter has also been tinkered with in the CU1 release of Exchange 2013. It looks like Microsoft is locking down on the configuration options of this feature in Exchange. You can no longer remove or create new Malware Filters. The only option is to work with the Default Policy that is present when Exchange is installed.

Exchange 2013 RTM


Exchange 2013 RTM CU1

The changes are also visible in PowerShell as you can see that the commands related to removing or creating a new Malware Policy are gone.
Exchange 2013 RTM


Exchange 2013 RTM CU1



There might be a fourth article if I find enough material to post on other changes in Exchange Server 2013 RTM CU1. Thanks for reading the article.

- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.