Recently had an issue where a user who was a carried over from Exchange Server 2003 way back when had multiple corrupt items. When he was originally migrated to Exchange Server 2010 there were a number of items which so how got corrupt. This inhibited his search abilities. With the New-MailboxRepairRequest command in Exchange 2016 I was able to resolve this issue.
I ran the repair against all options:
Once complete we recreated the user’s .OST file since he works in cached mode.
You can find more info on this at Technet:
I recently ran into an issue where one of my ESXi hosts reported errors with HA. I attempted to Reconfigure HA on this host which resulted in the following: Operation timed out.
I then attempted to reconfigure HA entirely – all the other hosts joined except for this one, disconnecting and reconnecting the host, and removing the host from inventory did not alter the behavior. For the life of me I couldn’t get this host to join. So I opened a support call.
I had a Dell based ESXi image installed on this host initially and I had applied a VMware based security patch to this host. Apparently mixing and matching is a no no, this was a known issue in their internal KB which was not open to the public. The only resolution was to reinstall the host (which did resolve the issue).
Maybe it is best to strictly stick to the VMware based images since vendor based images will usually be behind the curve when security flaws are known and a patch is needed to harden your ESXi host.
Again pretty straight forward – log into your vCenter using either the name or IP followed by :5480
Then select the Update tab. On the top right hand corner select Check Updates. Your vCenter appliance will check VMware’s repository if there are any applicable updates it will appear below. From there you can click Install Updates. Pretty simple.
So I needed to patch our vCenter 6.5 appliance due to a security flaw in our current version. When I tried to log in using the root password I was unable to do so. I know I had the correct password. Turns out I forgot the default expiration period which I had changed myself (should have set up a calendar reminder). The default I believe is 90 days as you can see here I set it to 365.
So now that my root password was expired, I was forced to change it. Luckily the steps are pretty simple.
- Log onto the ESXi box where your vCenter is homed, then console ino your vCenter.
- From there hard restart your vCenter box.
- When the Photon OS begins to initialize press the e key to enter the GNU GRUB editor
- Append the following to the 3rd line of code – rw init=/bin/bash
5. Press F10 to reboot
6. At the prompt type passwd – enter the new root password
7. Then unmount the file system umount / or reboot
The VMware KB arrticle can be found here for reference – https://kb.vmware.com/s/article/2147144
Recently while working with an third party vendor we came across and issue where the SQL Reporting Services displayed the error below when attempting to browse to the ReportServer:
The report server was unable to validate the integrity of the encrypted data in the database. (rsCannotValidateEncryptedData) Keyset does not exist (Exception from HRESULT: 0x80090016)
I first attempted to delete the encryption keys from the Reporting Services Configuration Manager but I was unable to do so. This wasn’t really ideal but since the server was not 100% in production now would be the time to take such a measure.
Below was the error:
I then recalled that when I initially set up SSRS I had used a different service account for the Reporting Service. It was changed at the vendor’s request. Once I had changed back the login account to the previous setup account the error was resolved.
Moving forward though I believe if I where to use a new account then the encryption keys would need to be deleted and SSRS would need to be reconfigured with that new account.
Ran into an issue today where we were unable to change Windows Update from Custom to Manual or any other setting.
In order to resolve this issue you need to create the following keys in the Registry using Regedit. They just need to exist in the registry in order for the change to take place within sconfig.
If you are sending emails to a Journaling connector and do not wish to journal voicemail messages for legal or business purposes you can disable this feature with the following command.
Set-TransportConfig -VoicemailJournalingEnabled $false