A Room or Room List disappears from Outook Scheduling Assistant

This case is really cool, and on a first look it looks like there is some magic involved. Help desk support engineer has escalated a situation with a "problematic" user mailbox and outlook. Whenever this user has been scheduled a meeting in a room or room list, the scheduled room(s) automatically disappears from the scheduling assistant list in a few seconds. It sounds like magic, and I've checked with my outlook, and I couldn't believe my eyes how room(s) disappears automatically in a few seconds when this users was scheduled a meeting and meeting room(s).
So, I've started digging the properties of this users mailbox and bumped on following invalid configuration :

WorkingHoursStartTime and WorkingHoursEndTime were having invalid time set. Changing these values to correct time settings can be done using the Set-MailboxCalendarConfiguration. For example:
Set-MailboxCalendarConfiguration - identity "affected user" -WorkingHoursStartTime 08:00:00
Set-MailboxCalendarConfiguration -Identity "affected user" -WorkingHoursEndTime 17:00:00
After changing these values to regular working hours, the magical disappearance of the meeting room(s) has ended when this user was also scheduled.

There is also published support article from Microsoft about this phenomenon on https://support.microsoft.com/en-ca/help/2852702/a-room-or-room-list-disappears-in-scheduling-assistant . It's stated that Exchange online is affected, but in my case I have experienced with Exchange on premise.

Happy Scheduling :)

VMM Service Crashes Repeatedly

In this case sysadmins were patching with latest firmware and drivers one of the Hyper V cluster hosts, due to unexpected server reboots. HPE support has recommended patching the server DL 380 Gen8 with latest firmware and drivers. So, latest PSP from HPE has been downloaded, and drivers and firmwares were installed.
Few hours later, after the installation of updated drivers and firmwares on the Hyper V host, VMM console of the VMM server which was managing the host has become unavailable. Also, System Center Virtual Machine Manager service on VMM server was terminating unexpectedly and event id 7034 was logged in system event log with information:
The System Center Virtual Machine Manager service terminated unexpectedly.  It has done this 3 time(s).
Since, the event doesn't say much about why the service was crushing, VMM debug logging has to be enabled using the following article https://support.microsoft.com/en-us/help/2913445/how-to-enable-debug-logging-in-virtual-machine-manager .
After enabling debug logging, the log was showing that error was generated whenever VMM was trying to reach the affected Hyper V server using WinRM and querying the WMI, for example (content truncated):
[Microsoft-VirtualMachineManager-Debug]4,4,WsmanAPIWrapper.cs,1913,WinRM: URL: [http:\\affected.hyperv.host]… 
[Microsoft-VirtualMachineManager-Debug]4,1,WsmanAPIWrapper.cs,3148,Retrieving underlying WMI error to throw. Got string ...
So, going back to the "updated" server and checking the update log, I've found that HPE Insight Management WBEM Providers were updated, and checked the following HPE article https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00053606en_us .
If Hyper-V is installed before Downgrade/Upgrade/fresh installation of HPE WBEM Providers, run the following steps after installing HPE WBEM Providers:
  • net stop vmms
  • mofcomp %SYSTEMROOT%\System32\WindowsVirtualizationUninstall.mof
  • mofcomp %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof
  • net start vmms
This will restore the Msvm_ classes under root\interop namespace that had been overwritten by HPE WBEM Providers.
After recompiling the "original" mof files, VMM functionality was back, and VMM was able to query the affected Hyper V host.

I hope this article will save some of your "precious" admin time in debugging of this kind of combination of Hyper V, HPE Updates and VMM, and … Happy patching :)

DNS Flag Day

Starting from today February 1, 2019 (DNS Flag Day), DNS (Domain Name System) providers will stop supporting DNS servers that are non compliant with Extension mechanisms for DNS (EDNS) protocol. In order to be compliant for EDNS, not only DNS servers should support this protocol, but also network devices (firewalls) should be aware for the necessary adjustments to support this protocol as a benefit for all us (internet users). Currently all major "players" are supporting DNS Flag Day.
For more info regarding DNS Flag Day, you can find on https://dnsflagday.net/. There you can also check your domain (hosting DNS zone servers) if EDNS is fully supported.
Microsoft DNS servers are supporting EDNS, but tests will show minor issue on implementation on some extensions of the protocol. Those errors will not affect domain name resolution on February 1, 2019 and later. According from Microsoft, those errors will be fixed in some of the next patch Tuesdays.

More info from Microsoft about this issue on Windows Server Domain Name System (DNS) Flag Day Compliance.
And, also please check if you're having some older network appliance which will prevent EDNS usage on your DNS servers. Please don't disable EDNS as a permanent problem resolution, Some DNS name queries are unsuccessful after you deploy a Windows-based DNS server.

Happy DNS Flag Day !

A Room or Room List disappears from Outook Scheduling Assistant

This case is really cool, and on a first look it looks like there is some magic involved. Help desk support engineer has escalated a situat...