[Resolved] Microsoft Exchange Notifications Broker stopped Exchange 2016

When you open the server manager on Windows 2012 R2 with Exchange 2016 installed you see an error stating that the Microsoft Exchange Notifications Broker has stopped.

This is by design with Exchange 2016 on-prem deployments. This is from the Exchange 2016 release notes.

Notifications Broker service stops after 30 seconds When you start your Exchange server, you might notice the Notifications Brokerservice start and then stop after approximately 30 seconds. If you attempt to start the service manually, it will successfully start and then stop, again after approximately 30 seconds. No errors or warnings are included in the Event log.

This behavior is expected in on-premises deployments of Exchange 2016. The Notifications Broker service performs a configuration check on each time the server starts. If there is nothing for the Notifications Broker service to do, it stops automatically until the next time the server is restarted.

As the error is very annoying and can look problematic this service check can be disabled in Server manager by selecting the drop down box next to 'services' find 'Microsoft Exchange Notifications Broker'

Listing all Exchange SMTP email addresses and aliases

Exports a list of Display names, Primary email address and any aliases and outputs them to a file on the C:\

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\exported-smtp-addresses.csv -NoTypeInformation

Port channel between Force 10 and Cisco switches goes down when one Force 10 in the VLT is rebooted.

Customer has a pair of Force 10 S4820 switches configured in a VLT domain. There is a port channel configured to a pair of Cisco C4510R+E connected via VSS. When one of the F10's is restarted the port channel on the surviving F10 goes down.

Looking at the default LACP timer settings a Cisco 4500, they are set to 30 seconds: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-7-0E/15-23E/configuration/guide/xe-370-configuration/channel.html#pgfId-1084922

(See “Configuring LACP Fast Rate Timer”)

On the Dell Force 10's they are set to short/fast (i.e. 1 second) already.

The options are stick with the static lag, or upgrade the IOS.

If you’re running a Supervisor Engine III or below then IOS v12 is the only option, therefore static lag.

Supervisor Engine IV or above will take IOS 15. 

The solution is this case was to upgrade the iOS on the C4510R+E and use the "LACP FAST RATE" on the port channel. If you can't upgrade the iOS then configure a static LAG.

Volumes connected to ESXi hosts via SAS to Compellent SCv2000 don't survive a reboot

Symptom:

ESXi 6.0 hosts connected to Dell Compellent SCv2000 via SAS experience an issue where by the LUNs do not survive a reboot. A rescan of the HBA's doesn't detect any LUNs.

Removing and re-assigning the LUN mappings for the hosts in Compellent Enterprise Manager works until the hosts are rebooted again.

Turns out that the 12Gb SAS HBA supplied by Dell is manufactured by Avago. The ESXi 6.0 2b image from the VMware website doesn;t have any inbox drivers from Avago so instead uses the LSI-MPT3 SAS driver. Whilst this appears to work from the outset, a reboot of the hosts proves that connectivity to the array isn't re-established after a reboot.

The solution is to remove the LSI-SAS VIB from the boot bank and install the Avago driver which can be downloaded from the VMware website: 

https://my.vmware.com/web/vmware/details?downloadGroup=DT-ESXI60-LSI-SCSI-MPT3SAS-10000000-1OEM&productId=491

After the package has been downloaded you will need to extract the offline bundle file with the ZIP extension and copy it to a VMFS datastore, in my example this is 'vol1'

Use putty etc to SSH onto the host(s). The first command removes the LSI-MSGPT3 VIB, a reboot is required afterwards. The second command installs the Avago VIB

esxcli software vib remove –n lsi-msgpt3
esxcli software vib install -d /vmfs/volumes/vol1/mpt3sas-10.00.00.00-6.0-offline_bundle-2803883.zip

Quickly move all the FSMO roles to a new DC with PowerShell

Move-ADDirectoryServerOperationMasterRole -Identity dC0 –OperationMasterRole 0,1,2,3,4

Moving SUSDB.MDF to another drive

Stop the services locking the SUSDB open

net stop "update services"

net stop "w3svc"

Use SQLCMD to drop the database.

sqlcmd -E -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -Q "sp_detach_db 'SUSDB'"

Use xcopy to move the SUSDB.mdf and SUSDB_LOG.ldf to the D:\

Reattach the database

sqlcmd -E -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -Q "sp_attach_db @dbname=N'SUSDB',\

       @filename1=N'D:\WSUS\SUSDB\SUSDB.mdf',\

       @filename2=D'D:\WSUS\SUSDB\SUSDB_log.ldf'"

Start the services

net start "update services"

net start "w3svc"

Protecting AD OUs from accidental deletion

Before carrying out an AD migration I always like to the the best practice analysers. 9 times out of ten these days we see that the BPA warns that all OUs should be protected against accidental deletion.

You can use the simple line of PoSh to protect all OUs and eradicate the BPA warning.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true