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 !

Outlook PST Cannot Be Accessed - Error 0x80040116

In this case, a friend of mine has complained to me that suddenly he couldn't access his emails stored in personal folder file (.pst) on his Outlook. He didn't have a valid backup copy of his Outlook personal folder file, and Outlook was returning error 0x80040116.

Before getting into resolution of the problem, let's first answer the question: What is personal folder file (.pst)? Well, the .pst file is a database file. So, like every other database file, it may become corrupt if not handled properly.

According from Microsoft KB319128, this error is related with disk problem and possible .pst corruption. From MSDN library and List of Extended MAPI numeric result codes, it can be seen that this error is disk related. So, running the chkdsk /r ( option /r locates bad sectors and recovers readable information ), has fixed several bad sectors on his hard disk . Fortunately, there were few bad sectors and hdd was small, so scanning the disk took around an hour and so.
After finishing the chkdsk scan, he tried to access his emails, and still no joy, error 0x80040116 was still present. So, now it was time to fix the pst file. For fixing the .pst files there are two options:
  • Native (out of the box) Office ScanPST.exe
  • Third Party solution for recovering PST files. There are tons of these solutions and I can recommend Stellar Phoenix Outlook PST Repair
For more information on how to repair pst file using scanpst.exe please follow the official Microsoft article How to repair your Outlook personal folder file (.pst)

In case of severe damage of .pst where scanpst.exe will not help, it's worth of trying Stellar Phoenix Outlook PST Repair. Demo version is free for downloading, and you can repair the corrupt .pst file and preview the recoverable items in it. If you get satisfied with the results, you can purchase the full version and save the recovered files. For more info regarding this product please checkout the official page Stellar Phoenix Outlook PST Repair.

So, what can we learn from this case is very simple, it's been said and written million of times and that is: Always perform regular backup of your valuable data.

Office 365 Unable to update object in Azure Active Directory

In this case there was O365 tenant with multiple federated domains. And after changing the UPN suffix for several users in on premise domain, those changes were not replicated in Azure AD. There was an error generated with following description:

Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.

There is a support article published by Microsoft with two workarounds on https://support.microsoft.com/en-us/help/2669550/changes-aren-t-synced-by-the-azure-active-directory-sync-tool-after-yo .
In previous cases Set-AzureADUser -ObjectId [DefaultDomainUPN] -UserPrincipalName [NewUPN], was sufficient for resolving the issues with Azure AD synchronization. Unfortunately, in this case executing this cmdlet generated the following error:

Set-AzureADUser : Error occurred while executing SetUser
Code: Request_BadRequest
Message: Property passwordProfile.password value is required but is empty or missing.Details: PropertyName  - passwordProfile.password, PropertyErrorCode  - PropertyRequired
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed

"Property passwordProfile.password value is required but is empty or missing" for the federated user, with ADFS configured and functional ?

Anyway, in order to resolve the issue, I've created new Microsoft.Open.AzureAD.Model.PasswordProfile object with "Password" and "ForceChangePasswordNextLogin" properties. Here is the powershell:

$AADPP = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$AADPP.Password = “strongP@ssw0rd1!”
$AADPP.ForceChangePasswordNextLogin = “False”

Now, I was able to execute the Set-AzureADUser with following syntax:

Set-AzureADUser -ObjectId [oldDomUPN] -UserPrincipalName [tenant.onmicrosoft.com] -PasswordProfile $AADPP
Set-AzureADUser -ObjectId [tenant.onmicrosoft.com] -UserPrincipalName [NewDomainUPN]

After successful execution of the above cmlets, Azure AD synchronization issues were solved successfully.

Office 365 Hybrid Federated User Free Busy (No Information)

There are a lot of posts regarding resolving free/busy issues, this post is one of them but with simple resolution. In this case it's Office 365 Hybrid implementation with multiple domains hosted in single O365 tenant. On premise exchange organization is Exchange 2013 with latest rollup installed. On premise ADFS is configured, and O365 on-boarded users can successfully access O365 resources using their on-premise domain credentials. Organization Sharing between domains configured successfully.
Having this configuration in place, O365 on-boarded users can collaborate with on-boarded and on-premise users successfully (and vice versa) including free/busy information. But, some O365 on-boarded users reported that they cannot see on-premise mailboxes free/busy information (No Information). Because the free/busy (no) information problem was not for all on-boarded users, but for some of them, the debugging of the issue has started on client level.
The debugging started with internet browser debugging options when connected to OWA and adding user mailboxes to scheduling assistant, and finding the POST request url https://outlook.office.com/owa/service.svc?action=GetUserAvailability... for the added user mailboxes. The response for the requests was "Error" with following information:

"<S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Receiver</S:Value></S:Code><S:Reason><S:Text xml:lang="en-US">Internal Server Error</S:Text></S:Reason><S:Detail><psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048820</psf:value><psf:internalerror><psf:code>0x800478ac</psf:code><psf:text>Provision is needed before federated account can be logged in.</psf:text></psf:internalerror></psf:error></S:Detail></S:Fault>Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received.   at Microsoft.Exchange.Net.WSTrust.SoapClient.EndInvoke(IAsyncResult asyncResult)   at Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult)   at Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)"

This user had a valid licenses assigned and can successfully access O365 resources.

Finally, the resolution for this issue is trivial, by connecting to AzureAD and changing the UserPrincipalName for this user to @tenant.onmicrosoft.com and then return back the UserPrincipalName. Here are the cmdlets:

Set-AzureADUser -ObjectId username@domain.upn -UserPrincipalName "username@tenantname.onmicrosoft.com"
Set-AzureADUser -ObjectId "username@tenantname.onmicrosoft.com" -UserPrincipalName "username@domain.upn"

After this action, the problematic on-boarded O365 user has successfully accessed the free busy information for the on-premise mailboxes.

Different Disk Size Information

This case might be a good question for some windows os certification exam. The scenario is that disk size shown in disk management console or diskpart for the affect disk drive was 120 GB, but from windows explorer disk size for H: drive was 105 GB. Here are the captured screenshots:

Disk management console


Windows Explorer


And, finally the reason for this behavior is simple hard quota template assigned for this drive, and here is the screenshot for the quota assignement:

Quota

I hope this post will help getting the answer for the question "How it is possible same disk drive to be presented differently in different parts of the operating system?".




















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...