EV11.0.1 SCOM EVWebsiteConnectivity.monitor error
Hello all, We use SCOM to monitor our EV environment, and we see on one of our installs the following alert: Source: http://evservername.domain.com:80/EnterpriseVaultAPI Full Path Name: evservername.domain.com\servername\Common\Server connectivity\http://evservername.domain.com:80/EnterpriseVaultAPI Alert Monitor: EVWebsiteConnectivity.Monitor Created: 20/04/2015 11:24:48 Alert Description: Cannot connect to website on server evservername. Website URL: http://evservername.domain.com:80/EnterpriseVaultAPI There are no events in the eventlogs (Enterprise Vault, System, Application). There are no issues reported using the search, There are no other issues reported. Does anyone know if this warning is a false alert? I do not see a reason to investigate or try to fix, but the SCOM team worries there is something wrong what needs to be fixed. this environment has been upgraded from 10SP4CHF2 to EV11SP1CHF1 on 18/04/2015 without issues. Thanks. GJ
Zapping a mailbox returns error [0x8004011D]
Hi All, Just thought I'd share this information as it drove me crazy for days. We had about 20 or sousers who could archive but restores would fail or hang, but after further investigation other symptons may vary. Basically when they tried to restore an email from the vault it would hang in the R1 queue and cause backlogs that simply wouldn't clear. I'm suspecting this could also affect the 'A' queues as well. When we tried to ZAP the mailbox it would fail with the below error, and I couldn't work out why! Error - Whilst processing mailbox with dn: (LegecyExchangeDN of user) [0x8004011D] I dtraced the EVPM with no success, or no valid errors that explained why (not sure if that was the right one to trace). In the end I remembered a similar issue with our BlackBerry's and checked the users LegecyExchangeDN in ADSIEDIT. Surprise! There was a space at the end of it! This is not something you can see in PowerShell... After removing the space from the end and trying again... SUCCESS! Not only did zapping now work but recalls worked as well. Be warned though, you cannot simply remove the space from the LegecyExchangeDN as you will break email for replies and cached entries in Outlook. You'll have to add the damaged LegecyExchangeDN as an X500 address to the users mailbox and then remove the space from the account either through PowerShell or ADSIEDIT (adsiedit is probably eaiser as you see what you are doing) Hopefully this will be helpful to someone...
Users unable to access their vaults
Hi all, I recently was involved in troubleshooting an access issue for a client. We managed to work out what was going on and I thought I'd share. Symptoms: Users were unable to access their vaulted items. If they attempted to do so, they would be prompted for credentials. Troubleshooting: To try to get to a root cause, I checked the user's Provisining Group membership from "Display Policies Assigned to Mailboxes". This was showing that the user did not have a provisining group assignment. The group membership list for the user was long and his membership list was even longer so I explicitly added him as a user and ran the task again. Still no good! My next step was to add a new group with a higher rank and then add him in. When I ran the provioning task this time it added him into the new group. I checked the event log and noticed the following error from the provisioning task run: The Exchange mailbox provisioning task failed to read required information from Active Directory. The task has stopped. Ensure that the Active Directory server is operational and the account the task is using to log on has read access to the required objects. Then run the task again. Task: Exchange Provisioning Task for foo.bar Domain: foo.bar Provisioning group: foo.bar group Group member: OU=Some OU,DC=foo,DC=bar AD server: GC://gc.foo.bar Error: Failed to read required properties from AD 'OU' object [GC://gc.foo.bar/OU=Some OU,DC=foo,DC=bar] - There is no such object on the server. For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp?EvtID=41129d Solution: Aha! My client had recently done some AD renovating and the provisioning task was failing when it encountered OUs in its list that no longer existed. Removing these objects resolved the issue. I hope this helps somebody! Cheers Ben
