Backup Exec: Single-item(s) Restore Fails with ApplicationImpersonation Error

Quick Answer: delete the registry key that relates to the proxy configuration settings.

Many years ago, if you wanted to restore items from a user’s mailbox that got deleted, you had to restore the entire mailbox.  It wasn’t a very effective manner, so Backup Exec started to allow single-item restore jobs through GRT restores.  One important thing to note is that in order for the restore to process, it has to stage the entire Information Store onto the Exchange server before it can extract the data.  That being said, make sure you have enough space on your server to hold at least two times the size of your Information Store.

Now to the task at hand: user Jane accidentally deletes a folder from her mailbox and has requested that it be restored.  This seems pretty straight forward, assuming that no Exchange Redirection option is selected.  An Information Store the size of 175 GB will take almost 2 hours to stage itself.  Once completed, it will attempt the restore.  However, you may come across the job failing for the following reason:

V-79-57344-905 – The resource credentials for the restore job were unable to create  a role assignment for ApplicationImpersonation. Review the credentials to ensure it has the rights that are required for ApplicationImpersonation.

Quick searches will bring you to Symantec KB articles like this one: http://www.symantec.com/business/support/index?page=content&id=TECH168297.  Assuming that you have set up Backup Exec properly, the information in such KB articles will prove to be completely worthless and a total waste of time, especially given that each attempt after minor tweaks will take 2 hours to process and leave you with the same ApplicationImpersonation error.  Quite honestly, it’s maddening.

If you have support with Symantec for Backup Exec (see below for details why I did not, which is 100% Symantec’s fault), then you could call them up and request support.  The initial support tier will send you to the same article (or similar ones; there are 3 that say the exact same thing for the most part), which again is more of your time wasted.  Once they have determined that the initial support level cannot help you, you’ll get elevated and pretty much start from scratch with the new tier, which will also take about a 3-5 days to find the resolution (if you are lucky, they’ll actually find it).  I know this because this is what I went through 2 years ago.  Because of our lack of a support contract (again, see below), I did not have this option, but thankfully saved all of the emails regarding this case and eventually found the answer after sifting through all the details:

SOLUTION:

On the Exchange server, you need to delete the following registry key (remember to export the key first, in case you run into any issues), which is related to the proxy server configuration:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\WinHttpSettings.

Delete this key, then retry the job.  It works.  None of the documents, KB articles, or forums that you will go to will ever mention this key.  The only reason I can offer is the same as my confusion: Why on Earth would the proxy configuration settings inhibit the ability to restore single items to an Exchange mailbox?

It is very important to note that this has to be done on the Exchange server and not the Backup Exec server.  Deleting the key form the Backup Exec server doesn’t affect the outcome.  If you are performing an Exchange redirection, I cannot say which server it needs to be performed on, but my gut says to perform this task on the server where the restore will finish on.

NO SUPPORT CONTRACT?

Every single year (for the last 7 years), I spend way too much time with Symantec to get all of our licenses and agents to start and end on the same date.  Managing support contracts this way is insanely more simple than multiple dates throughout the year.  This isn’t rocket science, but Symantec manages to screw this up every single time.  It doesn’t help that we changed our legal name, so it took 6 years to get all licenses to show the same name, which is obscene because that is very easy to take care of (still, Symantec messed that up, too).  Starting in 2012, they began giving me trouble with some of the renewals, stating that I didn’t have the licenses that I know I did have, despite showing proof.  This lead to weeks of discussions which resulted in my sales rep at Symantec falling off the face of the Earth.  I lost all contact, despite all attempts to contact him or his manager.  I had to then contact resellers who shoved me off to Symantec, who then said they wouldn’t help me.  I eventually got everything taken care of after contacting a head honcho who was quite appalled by the scenario, but it took 5 months to sort out.  Yes, 5 frustrating months to handle a simple request.  When all was said and done, I was promised that this would be the last time I would ever encounter this issue.

In the summer of 2013, it was time again to renew, but I ran into the exact same problem.  The Symantec sales rep would send me an Excel workbook that was beyond cryptic and includes companies/agencies that were not ours and expect me to figure out what we needed.  In addition, he told me that I couldn’t renew some because he had no record of me owning certain agents, which was complete hogwash; renewals are far less expensive than new purchases, hence why I was putting up a fight.  I then began working with a different sales rep after complaining to SMB renewals managers.  I was being forced to dig through all of my old purchase orders to prove to them that I did indeed have valid support contracts for all of my agents.  Even then, they toyed with the numbers and I spent weeks of back-and-forths with my sales rep just to get the quote correct so that I could process the order.  Yet once again, she fell off the face of the Earth.  This was started in June.  It is now November, and she and her manager will still not return calls or emails.  Let’s just say that I’m shopping for a new backup solution and that I will never ever deal with Symantec for anything ever again.

Advertisements

Crystal Reports Crashes when Inserting a Field = Dual-Monitor Issue

This problem initially occurred a few months ago for what appeared to be no rhyme or reason.  Other users weren’t having this problem and it was specifically tied to one computer.  Naturally, the thing to do on a single incident like this was to not spend hours researching the problem and just uninstall/re-install with reboots in between to clear up any possible setup corruptions, which initially worked.

Unfortunately, it happened again… to the same computer… with the same user.  At this point you start thinking about what’s different between this user and the other users that are not experiencing this problem.  The OS was the same (Windows 7), all using 32-bit architecture, all using the same version of Crystal Reports.  Perhaps it was a user issue, and we know how amazingly honest users can be about what they did.  However, I watched every step she did and there wasn’t anything behavioral about this problem.

A bit of  searching lead to this thread: http://scn.sap.com/thread/1495164.  While it dealt with a different version of Crystal Reports, what caught my attention was the fact that Crystal Reports does not support dual monitors.  I’ve run into a problem like this many times with dual monitors: a function within in application does not work for what appears to be no reason whatsoever, until you move the application to the primary window.  I had seen this with copy/paste functions, window display issues, scrolling problems, and now inserting a field in Crystal.  Once she moved Crystal to the primary monitor, the insert field function worked as expected.

The reason a re-install will work is because all applications default to opening on the primary monitor… until you manually move the application over to the other monitor.  Since Crystal was re-installed, it opened by default on the primary monitor and therefore the function performed as expected.  Once the user moved Crystal to the secondary monitor, the function caused the application to crash.

Now that we’ve figured that out, it all boils down to training staff to use Crystal Reports only within the primary monitor, which is sometimes harder to do than a re-install; old habits die hard.