I'm working on an existing EV 12.5.2 environment archiving from 4 x Exchange 2016 Servers.
The Web Access application was left set to 'Use TCP port 80' and now the management team wants to implement a certificate and configure it to port 443.
Exchange mailbox archiving has been set to create shortcuts and there are roughly 27 million items in the VS holding all of the e-mail.
So if I implement the certificate and change the port I know this will break all of the shortcuts and I did find an article saying you can re-run the archiving tasks in 'Shortcut Processing' mode with a registry entry to "repair" all of the shortcuts.
The million dollar question is how long is this repair process going to take? Has anyone done this before?
I do not believe there is a statement of 'how long' it will take, but it probably will run for ages.
I assume you have seen https://www.veritas.com/content/support/en_US/article.100017521
I hope you noticed:
Thanks for the reply GertjanA.
I did see the warning which is why I've been recommending against making this change.
I also opened a support case to see what guidance they may offer on this particular situation...if anything comes of it I will update this post.
I wanted to circle back on this one more time after finding a concerning statement in a Veritas technote about changing the protocol for the Web App after shortcuts have already been created.
the specific article is this one https://www.veritas.com/support/en_US/article.100038727
And it states:
Shortcuts in Outlook and Lotus Notes can be updated with the new protocol or port information using Synchronize mailboxes in the Enterprise Vault Administration Console, but customized shortcuts, FSA shortcuts and SharePoint shortcuts cannot be updated.
The concerning part is the "but customized shortcuts, FSA shortcuts and SharePoint shortcuts cannot be updated".
The mailbox policy shortcut content tab is set to "Custom" with 500 characters and show attachments as links. So if I'm reading this right then ALL of the shortcuts in the mailboxes cannot be updated??
Customer has chosen to go forward with enabling SSL on the Web Access Application.
An SSL cert was already applied to the Default Web Site so the change from 80 to 443 on the Web App was made in the VAC. After that I used an Exch Archiving task to synchronize the test mailbox and then ran the task with Process Shortcuts using the Reg Key RestoreShortcutBody = 1.
Now the shortcut don't open.
Double-clicking a shortcut opens just the shortcut with the grey banner at the top that says:
This item has been archived by Enterprise Vault. Click here to view the original item.
Clicking doesn't do anything at all. Any ideas on where to start troubleshooting this?
That is crap. I am not sure if below steps are correct, it has been ages when I had user mailbox archiving. Select Tab Enterprise Vault in Outlook. Select the offending Icon in folder in mail. press Left CTRL + SHIFT, then click an Enterprise Vault icon.
There should be a popup coming. That popup should have a button to show content or something. That is the information of the specific item. You can then check to see if the shortcut is indeed using https, if it is pointing to the correct archive, to which archive. You can then also see if the user has access to that archive..
From the machine where you tested the shortcut, can you open the "https:// ev server / enterprisevault/archiveexplorerui.asp (and the search.asp)? obviously, remove the spaces and use your ev server name
Yes I can hit the search page from a browser on the same machine.
When I looked at the details of the SSL cert I noticed that it does have the server hostname AND alias set as an alternate so I think it's setup correctly. However there are 2 other EV servers in this site and neither has a proper SSL cert installed. Could this be the issue?
That probably is the cause indeed.
Is it possible for you to fix the SSL certs on the other 2? I am not sure how the cert needs to look, but can imagine it requires the computername plus the 3 ev aliasses as alternate names. As you confirmed you can hit the search page, can you actually search the archive which has this troublesome shortcut.
I assume you open the search page on the server which has the proper certificate? Can you use the name of one of the other servers? does it open then?
I am able to reach the Search pages and can even recall the full item by URL.
What I found in the client logging was a call to "https://evserver/somelongpathtothearchiveditem".
I pasted "https://evserver/somelongpathtothearchiveditem" into a browser and got the 'There is a problem with the websites security certificate' warning. If I click continue it brings the full archived item up.
I checked my certificate and right now it's setup as such:
Common Name: evappa1.domain.com
Subject Alternative Names (DNS): evappa1.domain.com, evserver.domain.com, evault.domain.com
Since the URL from the client log is calling https://evserver/ and NOT https://evserver.domain.com/ I'm thinking this is the problem?
Should the certificate common name be the alias for the EV server? and then the DNS alternates are the fqdn, netbios, and alias?
Not finding a clear document for this.
I am not the one to ask, sorry. I have little to no knowledge on this, if I need certificates, I ask the team responsible for those to assist. (advantage of working in a large environment :) )