Dell iDRAC virtual media via remote console won't connect with error Channel Access Denied

Connecting the virtual media in a Dell iDRAC remote console fails with the error seen below. We had the latest firmware and tried the ActiveX and HTML5 consoles, but the problem was still there.

After inspecting the SSL certificate you can see that the date is invalid for some reason, we saw this on a new Dell server!

The solution is to reset the SSL certificate on the iDRAC with these commands:

racadm -r 192.168.0.120 -u root -p calvin sslresetcfg


racadm -r 192.168.0.120 -u root -p calvin racreset soft

Don't forget to change the iDRAC IP address, username and password to match your setup.

This process takes about 5-10 minutes to complete.

Broadcom QLogic iSCSI and FCoE HBA listed in ESXi storage adapters

When ESXi 6.0 is installed into a server with Broadcom, now QLogic 10GbE network adapters, we see a stack of storage adapters in ESXi.

This can be a drain on resources and increase LUN scan times. It also makes the GUI pane messy.

You can stop these from loading by disabling the following modules in ESXi 6.0 from either SSH or the DCUI

esxcfg-module -d fcoe
esxcfg-module -d bnx2fc

esxcfg-module -d bnx2i

After a reboot you will see that the Storage Adapters list much smaller.

[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