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

HP SPP 2017.10.1

HP has announced that the latest SPP 2017.10.1 for ProLiant will be available for downloading later this week. SPP (Service Pack for ProLiant) is a comprehensive HP systems software and firmware update solution.
2017.10.1 SPP contains components supporting the ProLiant, Synergy and Apollo Gen9 and Gen10 server platforms and options. It also adds support for RHEL 7.4 and SLES 12 SP3.

For more info please check:
http://h17007.www1.hpe.com/us/en/enterprise/servers/products/service_pack/spp/
 

Outlook search "Something went wrong and your search couldn't be completed"

In this case it's mine workstation with latest updates installed, and my first day after vacation with plenty of sun, beach, sand and sea. I was trying to get myself into working mode, so started with searching from tons of unread emails. (Un)fortunately, Outlook responded with "Something went wrong and your search couldn't be completed" .

After checking the application event log there was a warning event from Outlook source with id 36 and description:

Search cannot complete the indexing of your Outlook data. Indexing cannot continue ...(
error=0x81404005)

I thought my ost file got corrupted, so I've deleted the ost file and Outlook has recreated the ost file, but my Outlook search still couldn't be completed.
Fortunately, my internet browser search was working and found the Microsoft published article of known outlook issues after installation of latest June 2017 updates https://support.office.com/en-us/article/Outlook-known-issues-in-the-June-2017-security-updates-3f6dbffd-8505-492d-b19f-b3b89369ed9b . My issue is described as issue #5, with workaround of disabling the indexing.


There is a announcement that today 27/6/17 there will be Windows update fix for this issue.
So, until the fix is published, disable the Outlook indexing with steps described as workaround in the article, or do not try to search :)

Searching For Email Groups Without Members

This is quick one for a reference, searching for AD groups with present email address, but without members using LDAP filter and powershell:

 Get-ADObject -LDAPFilter "(&(objectcategory=group)(!(member=*))(mail=*))" 

Same LDAP filter can be used with Active Directory Users and Computers:

Happy hunting :) 

Exchange 2007 support will end next week

Just in case you've missed the date, Microsoft will end support for Microsoft Exchange 2007 next week. On April 11,2017, Microsoft Exchange 2007 will reach end of life.
This means that Microsoft will no longer provide for Exchange 2007:

• Free or paid assisted support (including custom support agreements)
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

For more info checkout the Microsoft Exchange Team Blog  https://blogs.technet.microsoft.com/exchange/2017/02/27/exchange-2007-reaches-end-of-life-on-april-11th-whats-your-plan-to-move/
For more info about lifecycle policy checkout the official article on https://support.microsoft.com/en-us/help/14085/microsoft-business-developer-and-desktop-operating-systems-policy .
And for searching the lifecycle product database use the following link https://support.microsoft.com/en-us/lifecycle/search .
 

VM saved state during backup from Hyper V host

In this case, Windows Server 2008 R2 was P2V (physical to virtual) converted, and hosted on Windows Server 2012 Hyper V cluster. This VM was having several vhds attached, and latest integration services available from Hyper V cluster were successfully installed and running.VMs running on this Hyper V cluster were backed up from Hyper V hosts. During the backup schedule this "new" VM, was the only one that was going into saved state during the backup, and services hosted on this VM were unavailable for several minutes. Backup of the VMs is VSS based, and there were no VSS errors.
In this situation, I've checked the backup solution documentation and found that this behavior of saving the state of the VMs is under jurisdiction of Hyper V, and not under control of the backup software.
So,  I've started digging the Hyper V logs and found something interesting: during the backup cycles there was warning event 4098 logged into Hyper V Integration event log:

 This event was logged for the VM that was going into saved state during backup. So, I've checked the VM's scheduled volume shadow copies, and found that shadow copies for volumes were stored on separated disk only for storing shadow copies.
After changing the scheduled volume shadow copies to be stored on same disk as data, the VM was successfully live backed up from the Hyper V host without saving state and without losing the VM's offered services during the backup.

SHA1 RIP

It was announced that SHA1 have been broken in practice. On following post https://shattered.it/, you can learn how dangerous is becoming to still use this cryptographic hash function. Basically, now it's possible to have or create two different documents with same hash SHA1 signature.
For example: on shattered.it there are two pdf documents (shattered-1.pdf, shattered-2.pdf) with different contents but with same SHA1 hash ! If you don't believe the shattered.it, you can download the example pdfs locally and generate the SHA1 hash, for example using powershell and
Get-FileHash cmdlet:

If you don't believe your eyes, try it yourself :)

And finally as a simple conclusion, with this publicly available example in mind, I think it would be the best for your data, to start making plans for replacing SHA1 with SHA2 algorithm ASAP.

Missing rule in Outlook

In this case, scheduled meetings to a user were mysteriously forwarded to a group of users. Helpdesk engineers have removed all the rules that could be seen for that user mailbox, and again all scheduled meetings for that user were again forwarded to this particular group of users. Helpdesk team escalated this user issue to Exchange admins in order to do same tracking. And from Exchange tracking logs can be seen that scheduled meetings were forwarded by mailbox rule ?!?!? :

But, where is that rule ? Get-InboxRule for this user mailbox returned nothing, because helpdesk engineers have removed all the rules, and still there is a rule in this user mailbox that is forwarding the scheduled meetings. So, obviously there is a rule corruption for this user mailbox, and MFCMAPI is your friend. Latest version of this tool can be downloaded from codeplex http://mfcmapi.codeplex.com/ .


Please follow this article https://blogs.msdn.microsoft.com/hkong/2015/02/27/how-to-delete-corrupted-hidden-inbox-rules-from-a-mailbox-using-mfcmapi/ , to learn how to delete corrupted rules with this very powerful tool.


After deleting this corrupted rule from the user mailbox, no other scheduled meetings were forwarded from this user to the particular group of users.


And again, please be very careful when using MFCMAPI in order to avoid corruption.