To check the status of current/previous backups whether they are full/differential or incremental with the following command in Exchange powershell:

Get-MailboxDatabase -Status |FL *backup*

The results will show up liek follows:

BackupInProgress                                   : False
SnapshotLastFullBackup                      : True
SnapshotLastIncrementalBackup    :
SnapshotLastDifferentialBackup     :
SnapshotLastCopyBackup                  : True
LastFullBackup                                        : 08/05/2014 11:02:32
LastIncrementalBackup                      :
LastDifferentialBackup                        :
LastCopyBackup                                     : 07/02/2014 15:30:14
RetainDeletedItemsUntilBackup    : False

First we need to find which domain controller holds the FSMO roles.  To do this we start up powershell on one of the domain controllers and type:

netdom query FSMO

The results should show up 5 roles with the domain controller it resides on.

The 5 FSMO roles are numbered 0-4:

0 – PDCEmulator
1 – RIDMaster
2 – InfrastructureMaster
3 – SchemaMaster
4 – DomainNamingMaster

In this example the FSMO roles sit on DC01.  We would like to move them over to DC02.

Move-ADDirectoryServerOperationMasterRole -Identity “Target-DC” -OperationMasterRole 0,1,2,3,4

So for our example we use:

Move-ADDirectoryServerOperationMasterRole -Identity “DC02” -OperationMasterRole 0,1,2,3,4

Simple, its that easy.  Press ‘A’ to apply to all FSMO roles or ‘Y’ to choose each one.

1. Backup the CA from 2008 R2 server using the “Backup CA” option in Certificate Authority to a folder.  Make sure the folder is empty.  Copy this folder over to the new 2012 R2 CA.

2. Uninstall CA from 2008 R2.  Remove from domain.

3. Add CA feature in Server 2012 R2 using Powershell.

Import-Module ServerManager

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

4. Finish the configuration of the CA through the Server Manager (top right).  Import the existing CA certificate.

5. Launch Certificate Authority and restore the backup you created in step 1.

6. CA should now be running on Server 2012 R2

I’m currently testing Backup Exec 2014 Beta 1 and came across an issue with deploying Backup Exec Client to the TMG boxes.  EMS server was absolutely fine.

So basically I enabled the TCP port range from the default 10000 to a wider range of 1025 -65535 under Main menu>Configuration & Se tings> BackupExec Settings> Network & Security> Tick Enable TCP Dynamic port Range.

Now we set a port on each TMG box for listening to ndmp (default is 10000).

Go to c:\Windows\System32\Drivers\etc\ and open in notepad services

add the following line at the end:

ndmp       12000/tcp         #RAWS

Save the file and close.  Now restart the backup exec service on TMG box and it should start up fine.

Microsoft Exchange Version: 2013

Tested on: Cumulative Update 3

OS: Server 2012 R2

Exchange 2013 tends to have an increased amount of application logging enabled by default. This logging is different from the Exchange database logs.

Exchange 2013 requires around 30GB of free space in the disk where Exchange 2013 is installed. Yes you read that right a whopping 30GB! Compared to Exchange 2010 which had a reasonable 1.2GB. So why the drastic increase is application logs? Well Exchange 2013 has a lot of default performance, application and other component monitoring enabled by default. Stuff which some will never use and other stuff that you *may* use on a blue moon.

If LUN allocation/capacity is an issue in your environment like it is in mine; then utilizing this precious disk space on a mailbox database / mailbox database logs is more comforting.

So you have 2 ways to fix it:

1. Increase disk space continuously as it grows. (Basically be a lazy Exchange administrator and fix the problems as they arise). OR

2. Run a script to clear out the unnecessary log files.

Before we continue you want to make sure these log files will not be required in the future for any sort of performance monitoring or IIS user audits etc. So if you have a legal department or HR investigation into users doing something they shouldn’t be doing then I would recommend sacrificing the extra disk 30GB space. If not then read on.

So there are two parts to clearing out the logs:

First check how much space your current logs are using (DISK:\Program Files\Microsoft\Exchange Server\V15\Logging) as a future reference:

Within the “Logging” directory you will see folders like these:

So now you can see the hefty folders under the Logging directory.  Out of all these the folders we are mainly interested in “Diagnostics/DailyPerformanceLogs” – here you see the the culprits:

These files basically hold information of the your servers running Exchange 2013 with parameters such as CPU, memory, disk, IOPS etc for diagnosing performance related issues.  Now in the older 2010 environment when contacting Microsoft support for diagnostics they would ask you to run performance monitoring and gather the data delaying the process to fix any issues.  In Exchange 2013 these are ready at hand with a historical copy stored in the above mentioned directory.  So you see Microsoft were being smart.

To manually clear out any logs that are not required for the running of Exchange 2013 we run the following command in a administrative powershell window (normal powershell will do).

gci ‘D:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-7) | Remove-Item

In the above script any files that are older than 7 days will be deleted.  You can increase or decrease this value as it suits your needs.

We will now schedule this to Windows Task Scheduler to automate this process.

Create a new task (not basic) and name it whatever you wish.  I will name mine “Clear Diagnostic Logs”. Make sure you select “Run whether user is logged on or not” option.  Also enable “Run with highest privileges”.

Now we set the time.  Mine is scheduled every morning at 7.45am.

Next is to add the powershell.exe program to the action tab and place in the script.

Now to do a test run to see if everything is OK we need to enable “Allow task to run on demand” under the Settings tab.

Run a test run and you should see “Task Completed” under the history tab.