Couple of Words About Microsoft Certification in the Unified Communication Area

Hi folks,

I have just recently obtained my MCSA: Office 365 certification. So I just wanted to share something I have discovered about certification programs with Microsoft.

As you all well know, in 2012 Microsoft returned from MCTS/MCITP certification back to MCSA/MCSE. In order to get your MCSE certification as in old good day you need first get MCSA and then pass 2 specialization tests and get your MCSE. It's a little bit easier than the original MCSE certification,as it doesn't require anymore to pass tons of other exams but rather focus on spealization.

Originally, when you were seeking MCSE: Messaging or MCSE: Communications certificate you had first to obtain MCSA: Windows Server 2012 certification first and then you could do 2 exams in either certification. However in 2014 Microsoft has introduced MCSA: Office 365 certification which is now alternate way to get your MCSA.

So now you are presented with 2 options to obtain your MCSE in UC are: you either obtain: MCSA: Windows Sever, which is actually a requirement for other MCSE certifications in Server and Desktop Infrastructure. Thus you are getting higher horizons open before you. And also, please note that this is an upgrade path from MCITP to MCSE. Or you can obtain MCSA: Office 365 and thus keep your mind focused in your specialization area. Either way would bring you to MCSE in Exchange and Lync.

So to get MCSA: Office 365 you will need to pass exams with code 70-346 and 70-347. If you want to obtain MCSE: Messaging, you will need afterwards to pass 70-341 and 70-342. By the way 70-342 is a very tough exam so prepare well and do a lot of TechNet or Exchange 2013 CHM file reading before you sit at this exam. And if you want to get your certification in MS Lync aka MCSE: Communications then you will need to pass 70-336 and 70-337. I can't say any word about the later because I haven't yet studies for them or sat at them.

However, it's worthy to mention that Microsoft is to issue new versions for all its server products and the OS, so who knows may we will face another certification routes change.

But anyway I hope this article is helpful for you to make your right decision.

Enjoy.

Performing Exchange 2013 Server Update to the Next Build

Hi folks,

I have recently been involved in activity of upgrading Exchange 2013 server to a later build (CU5 in my scenario).

As you're probably aware there's a new architecture in Exchange 2013 which involves only 2 roles and also MS has paid high attention to the high availability to reduce downtime for Exchange servers. The component that helps achieving this high availability by monitoring every Exchange component and making sure it's up and running. If it can't restore a component it will fail database copies to another server which has all the components healthy. More on Managed Availability can be found here.

Taking this into account there's the whole process of preparing a server for upgrade and then restoring back to its functionality. In fact this can be useful for those who are getting ready for the 70-342 certification exam to achieve their MCSE: Messaging certificate.

Before upgrading your Exchange server you need to ensure that it has no active mailbox database copy running on it and that there's no mail being routed via this server, Additionally any database copy failover to the server being upgraded should be prevented.

The following is the process for preparing a server for the upgrade:

1. We let need to drain all the transport queues on the server to avoid new messages being sent/received by it

Set-ServerComponentState SERVER1 -Component HubTransport Draining -Requester Maintenance

Redirect-Message -Server SERVER1 -Target SERVER2.contoso.com


Please note that you will need server FQDN for the Target parameter in the second command

2. Suspend node in the DAG:

Suspend-ClusterNode -Name SERVER1


3. Prevent database copies being activated on the server:

Set-MailboxServer SERVER1 -DatabaseCopyActivationDisabledAndMoveNow $true

Set-MailboxServer SERVER1 -DatabaseCopyAutoActivationPolicy Blocked

Set-ServerComponentState SERVER1 -Component ServerWideOffline -State InActive -Requester Maintenance


After this we can perform server upgrade either by running GUI or in unattended mode (my favoirite one) by executing:

setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

Of course, don't forget to navigate to the folder that contains the latest Exchange 2013 binaries.

After this you make yourself a cup of tea or coffee and wait for the installation to complete. When installation is over you will need to ensure that it has run successully and remove server from the maintenance mode.


To ensure that upgrade didn't mess anything up you will need to ensure that that all Exchange services are up and running by executing

Get-Service -Name *exchange* |ft -AutoSize

Make sure all the critical services are in the Started state


When all services are up and running and healthy, you are OK remove servers from the maintenance mode by restoring server's ability to send/receive email and to host active mailbox databases:

1. You activate server and its components and endpoints:

Set-ServerComponentState SERVER1 -Component ServerWideOffline -State Active -Requester Maintenance

2. You resume cluster (DAG) membership:

Resume-ClusterNode -Name SERVER1

3. You enable server to host active mailbox database copies again:

Set-MailboxServer SERVER1 -DatabaseCopyAutoActivationPolicy Unrestricted

Set-MailboxServer SERVER1 -DatabaseCopyActivationDisabledAndMoveNow $false

4 Finally you enable transport component on the server to send and receive emails:

Set-ServerComponentState E15MB1 –Component HubTransport –State Active –Requester Maintenance


After this you locate scripts folder and execute RedistributeActiveDatabases.ps1 to make sure that mailbox databases are redistributed according to their activation preference.

cd $exscripts

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$false

After servers are up and running we can do some more tests to ensure that installation and post-installation tasks have been successful:

1. Check if all services are healthy by executing Test-ServiceHealth

2. Check health of mailbox database copies located on the server Get-MailboxDatabaseCopyStatus (by default command defaults to the local server)

3. Check if replication is working by executing Test-ReplicationHealth

4. Check if nothing is left in maintenance mode by executing

Get-ServerComponentState -Identity SERVER1

Ensure that all the components have state of Active

After this you are OK to upgrade your other servers and operate the current one.

Enjoy!

Exchange 2013 UM Services Start Up Issue on Windows 2012 R2

Hi folks,

I have recently had to deal with the problem of Unified Messaging (aka UM) components not being able to start on a Exchange 2013 multi-role box. I will not dwell explaining what the UM in Exchange 2013 is because it can be found here.

I'd rather share with you what were the symptoms and what was the magic bullet in my case.

First of all both Microsoft Exchange Unified Messaging and Microsoft Exchange Unified Messaging Call router services would fail to start. I had both of these services on my server because it was a multi-role box. Manual attempt to start them would fail with the error 1067: The process terminated unexpectedly.

When checking Event Viewer I have discovered there are errors with ID 4999 and 1038 found in the Application log and 7031 (for each of the service in the System log.

When searching for solution in Google and Bing I was pointed to different articles and forum discussions. Each person posting his/her post was missing this or that component which would prevent successful start of the UM services. In some cases people were missing the right certificate, while in others some files were corrupted, even UMWorkerProcess.exe. Recommendations were different, including re-installing Exchange binaries on the server. Each story would end up either with success or failure.

Checking my server and found out that UCMA 4.0 was missing. Actually, UCMA 4.0 is one of the  Exchange 2013 prerequisites which should be installed on a Windows server before the installation of Exchange binaries.

Finding this out made my solution quite successfuly. I have downloaded UCMA 4.0 installation file from here and installed it on my server. Installation is straightforward. All you need is to press Next button couple times and wait till UCMA is installed on the server.

After this I have restarted my server (after all it's running Windows OS) and the services have been restored to functionality. Server Manager dashboard became shiny and both UM and UM Call Router services successfully started and all the dodgy events have stopped being logged to event logs.

Enjoy

Reviving EMS in Exchange 2013

Hi folks,

Just wanted to share with you about the latest adventure that I had with Exchange 2013.

We have recently launched Exchange 2013 lab to play with the new features and also prepare for the future Exchange update. We installed Exchange on the Windows 2012 R2.  However, after installing servers we were greeted by the bad surprise. When we launched Exchange Management Shell (aka EMS) we have received the error like this:

As I have started my investigation the first thing that took my attention that one of the important registry keys is missing, namely HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine.

I have started googling and there were all different kind of advises given. One of them was like this one where it was advised to export the same key from Windows 2008 R2 and import it to Windows 2012 R2 box. This wouldn't work. Fortunately it was lab and there was no negative impact.

Further investigation lead me to this article. The solution it was proposing to install PowerShell 2.0 Engine windows feature which has made the magic. You can use Server Manager or Install-WindowsFeature cmdlet to install it.

After installation I restarted the server and it made the magic and EMS functionality has been restored. Optionally you can run iisreset command (however make sure that you run is as admin) to achieve the same without restarting.Missing registry keys have been restored and PowerShell has started without any problems.

This is the universal solution for all the servers which is working.

However there were couple other problems on the other servers. In one case EMS wouldn't start because of the problems with remote PowerShell. It couldn't connect to remote PowerShell with the error 403.

Further investigations pointed me that 2 websites hosted by IIS on this box are configured with wrong ports. We have installed our Exchange 2013 boxes as multi-role servers. It means that Exchange creates 2 websites in IIS: Default Web Site for CAS role and Exchange Back End for mailbox role. Exchange clients are connected to CAS on port 443 and then are redirected to port 444 on the Mailbox server where all the client protocol data processing is happening. In case of PowerShell ports 80 and 81 are used respectively. More information about how IIS is configured for Exchange 2013 you can read in this Microsoft article about Exchange 2013 Web sites and virtual directories.

In my case I ran Get-WebSite cmdlet and discovered that Exchange Back End website is listening on port 80 and Default Web Site is listening on port 81.

On the properly configured box it should be configured other way around, as on the picture below. I have configured Default Web Site to listen on port 80 and Exchange Back End to listen on port 81.

After restarting the server I could successfully run EMS, it proved to be successful and I managed to connect to PowerShell and do normal admin works,

Finally on the other server EMS couldn't connect to the local server because World Wide Web Publishing Service and Windows Process Activation Service were not running. Attempts to start them wouldn't succeed. In the System Events log i would get errors 7001, 7023, 5005 and 5036.

Both of the services wouldn't start due invalid data. Investigation pointed me to this article and this advice. When I have accessed C:\Windows\System32\inetsrv\config I have discovered that the applicationHost.config file was empty that therefore consuming only 0 KB on the disk. I have renamed the file (optionally you can delete it). After this I went to the C:\inetpub\history folder which contains backups for the config and XML files that were recently changed. I have found the latest version of the file and copied it back to C:\Windows\System32\inetsrv\config . It made the magic and as a result after server restart World Wide Web Publishing Service and Windows Process Activation Service started successfully.

Executing EMS succeeded as the result.

I hope this helps you to spend less time on this issue comparing to the time I did.

Enjoy.

Extract Average Mailbox Size for Exchange 2013 Capacity Planning

Hi folks!

Currently I'm working on the planning of the capacity for new Exchange 2013 solution, namely upgrade from Exchange 2010. To plan server and storage capacity I'm using Exchange engineer's little helper, namely Exchange 2013 Role Requirement calculator. Recently Microsoft has published version 6.6 of it for Exchange 2013 which can be found and downloaded from here.

One of the new inputs that has been introduced Initial Mailbox Size (MB). It helps you to predict how soon will you reach the mailbox maximum size that you define in the Mailbox Size Limit (MB) input.

If you are building a brand new Exchange solution you will need to place value of 0 there. This will give you the following storage usage model by mailboxes for each mailbox tier which can be located on the Mailbox Space Modeling page of the calculator. In my case I set maximum size of the mailbox to be 25 GB (25600 MB) for each profile and the whole mailbox space would be filled within 60 months or 5 years.

However things change when you are upgrading the current Exchange 2007/2010 environment, as I do. In this case you will need to populate Initial Mailbox Size (MB) with the value of the average mailbox size in your current DAG to get more accurate prediction on when mailboxes that will be migrated to Exchange 2013 will reach their maximum size.

To achieve this I used yet one more Exchange engineers later helper, namely PowerShell. Of course your scenario can be different for mine. But let's imagine the scenario when you have DAG named DAG01 and DBs within this DAG are named DAG01-DB01, DAG01-DB02 and so on. Having such a contiguous naming convention will allow you to easily retrieve mailboxes from you databases that are part of your DAG.

So in my case I first create the variable which contains all mailboxes which reside in the mailbox databases within DAG. With naming convention like mine you can easily filter databases by using part of this name which common among all the databases:

 $MBXS = Get-Mailbox -ResultSize Unlimited |where-object {$_.Database -like "*DAG01*"}

To ensure that the variable has been properly populated you may output it to the screen or CSV file using Export-Csv cmdlet.

After this we need to execute Get-MailboxStatistics cmdlet against the mailboxes populated in the variable. The attribute that is interesting to us is TotalItemSize which gives us info about the size of the mailbox. We convert this value to the numeric value and the count the average value for all mailboxes by using Measure-Object cmdlet with -Average parameter. So the code for this looks something like:

$MBXS| Get-MailboxStatistics | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -Average

This should output the average number on the screen which you can then use in your role calculator.

This works fine when command is executed in the Exchange Management Shell locally on Exchange server. However, there may be a problem when this command executed from the local workstation that is talking to Exchange server via remote PowerShell. Instead of $_.TotalItemSize.Value.ToMB() you will be getting blank values. MS has advised the following workaround in their Technet Blog article. You will have to replace TotalItemSize.Value.ToMB() with @{name="TotalItemSize (MB)"; expression={[math]::Round(($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}} 

As a result it retrieves information to the screen like below

However it won't be able to retrieve average because the numeric value is actually string against which average can't be calculated. I would get screen as below:

To overcome this I extracted output into Excel spreadsheet as below:

 $MBXS| Get-MailboxStatistics | select DisplayName,@{name="TotalItemSize (MB)"; expression={[math]::Round(($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}} |Export-Csv DAG01-SizeReport.csv

And finally in Excel all you need is to calculate average mailbox size using good old AVERAGE function which gives us a value that we can use in the calculator for the Initial Mailbox Size (MB)

As a result we are getting more accurate prediction on how soon maximum mailbox size will be reached when we migrate from the existing Exchange solution to Exchange 2013.

I hope this will help you as it did help me.

Enjoy

Quick Bulk Mailbox-Enabling

Hi folks,

This is just a quick post for those of you who provision bulks of mailboxes on the regular basis. This scenario assumes that user accouts have already been created in the AD.

All you need to is to have TXT or CSV file with the UserId header. Underneath it you can publish one of these values to identify user accounts which can be wither of the below:

• GUID
• Distinguished name (DN)
• Display name
• Domain\Account
• User principal name (UPN)

As soon as the input file is ready you can import it into the pipe and enable mailboxes for each user ID in the file. And it's only one string as follows:


Import-Csv D:\Scripts\Users.txt| foreach {Enable-Mailbox -Identity $_.UserId}

Very helpful for lazy guys like me.

Enjoy.

Getting Your User Accounts Activity Under Control

Hi folks,

This is my first blog entry in 2015. Just wanted to share about my recent adventure.

All of you who manage messaging environment have test accounts that are being created and then abandoned and sitting in your AD forever. Or you may be want to avoid a situation when all of them are in use thus creating extra load on your messaging system, especially if there is too many of them.

This is where our good old friend PowerShell comes to play. In this scenario I used Get-ADUser command which is available in the Active Directory module which comes with Windows 2008 R2 and later.

The best way to identify user activity is to extract information about logons and password changes. I prefer to be using both as in some cases password for accounts (even test accounts, can you imagine this!) is set to never expire. So in addition to password set and changes related attributes I used LastLogon attribute.

Additionally it's worthy to mention scenario when you are in a forest with multiple domains (which is not the best practice according to Microsoft). You may connect to multiple servers or in my case I simply used global catalog to extract the information I needed. To user global catalog you will need to type server host name followed by the 3268 which corresponds to the port GC is listening for LDAP requests.

Please note the attribute msDS-UserPasswordExpiryTimeComputed which is used to calculate password expiration date.

And last, but not least don't forget to import AD module for PowerShell to be able to successfully execute the script.

My final code looks like this


Import-Module ActiveDirectory
Import-Csv D:\scripts\Users.txt | foreach {Get-ADUser -Identity $_.samAccountName –Properties * -Server GC01:3268} |
Select-Object "Displayname",SamAccountName,whenCreated,LastLogonDate,PasswordLastSet,PasswordExpired,PasswordNeverExpires,@{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}} |Export-Csv D:\scripts\UserActivity.csv

And it produced a nice spreadsheet as below:

Please note user accounts with the blank value for LastLogon which indicates that user has never logged in to the AD domain. In addition to that some of the dates may be a long way in the past. Both may indicate that user accounts might not be in use and therefore a good candidates for deletion. But please make sure that you contact the account or service owners before doing so.

And, finally, my special thanks to the author of this great article which gave me a good hint on the way to go.

Enjoy.