Jump to content
Sign in to follow this  
awnews

Outlook force quit & restart

Recommended Posts

I usually leave MS Outlook 2000 running on my W2K SP3 PC, with the app usually open to the Contact file (note: I don't use Outlook for mail or as a calendar and I'm not linked to an Exchange server). For the last couple of weeks I've frequently looked at my PC in the morning and found that Outlook had quit and there as an error message saying that Outlook couldn't do something (sorry, I didn't write down the exact text)--access something, complete an operation, etc.

 

 

 

I finally realized the cause--Retrospect Pro 6.0 RDU 3.2.104. The new RP6 version has the "Force backup of Microsoft Outlook data" script option (on, by default). So it seem as if RP6.0 is managing to close Outlook but there's either an issue during the forced quit or RP6.0 is unable to restart Outlook after completing the backup.

 

 

 

For now I've disabled the Force quit feature for the script.

 

 

Share this post


Link to post
Share on other sites

Please provide the exact text of the error message displayed by Outlook.

 

 

 

Also, are you using the Open File backup add on?

Share this post


Link to post
Share on other sites

I was able to duplicate the problem, with W2K SP3 and MS Outlook 2000 open, and here's what I got:

 

 

 

1) Manually ran RP6.0 script to backup my C: drive to a backup drive (R:) on the same system. Outlook was shutdown and reopened with no error message.

 

 

 

2) Manually ran RP6.0 script to backup my D: drive to a backup drive (R:) on the same system. Outlook was *not* shutdown or reopened and there was no error message--this makes sense since Outlook only stores its open file(s) on the C: drive so there's not need for RP to shut it down when backing up this second drive.

 

 

 

3) Added a "one time" schedule to the script to backup my C: drive to a backup drive (R:) on the same system (same script as in #1 above). This time RP managed to shutdown Outlook but the error dialog came up when RP tried to restart Outlook:

 

 

 

(X) Could not complete the operation because the service provider does not support it. [OK]

 

 

 

A "Microsoft Outlook" process is visible in the taskbar but it's just the error dialog and closes when I click on the [OK] for the error dialog.

 

 

 

So the difference in #3 is that Retrospect Launcher launched the script. Hopefully the timeframe (failed on the reopen) means that RP6.0 was able to shutdown Outlook and backup its files successfully. Note again that I'm *not* using Outlook to check email (auto check is even disabled) or connect to an Exchange server or anything else on or off my LAN (firewall connected to the Internet via cable modem).

 

 

 

Note that I *do* have Retrospect Launcher set to run with my account name (which is an admin-level account) and password rather than the LocalSystem account. I need to do this anyway since I also use RP6.0 to backup my C: drive to another backup drive on another PC across my (Workgroup) LAN and need admin permission to access its drives via the Admin share (e.g. \\OtherPC\J$). Since this works, I know the admin-level name & password (has to be the same on both PCs under W2K workgroup protocols) is correct--the RP6.0 backup would fail if the name & password weren't the same.

 

 

Share this post


Link to post
Share on other sites

I don't know if I'll give that a try or not. Perhaps the line of thinking is that the script is running with my login permissions but the quit & restart of Outlook is running at Local or needs to run at Local? When I run the whole thing manually, I assume that everything (script running and Outlook quit & restart) runs with my login permissions.

 

 

 

I understand that you're proposing it as a test (although I think I've gone above and beyond with the debug work I've already done...) but it's obviously not a practical solution to anything since I *have* to run with my login admin permissions so that Retrospect will have network access permissions.

Share this post


Link to post
Share on other sites

OK, so I broke down and ran an unattended scheduled backup of my C: drive, with MS Outlook 2000 running, with Retrospect Launcher set up to run as a LocalSystem account. And I did then *not* get the "(X) Could not complete the operation because the service provider does not support it. [OK]" error dialog that I previously reported. Outlook did quit and restart automatically while Retrospect (RP6.0, RDU 3.2) was running.

 

 

 

I then of course changed Retrospect Launcher back to my personal admin-level account since I *have* to run that way for Retrospect to work across my network.

 

 

 

I did notice something in the Operations Log. In the normal case, with the Retro Launcher set to run as my admin account and me logged, when RP6.0 (and RDB5.6 before it) runs, I always get one error, a "C:\WINNT\system32\Preflib_Perfdata_498.dat": can't read, error -1020 (sharing violations)" in the Retro log. If I'm not logged in when the backup is run (usually because I've booted the PC but haven't yet logged in), I don't even get that error.

 

 

 

In the case I just tried (letting Retro Launcher run as LocalSystem account), I still saw the same "Preflib_Perfdata_498.dat" error. But I *also* saw a couple of other sharing violations related to other programs. Since we're focused on Outlook, the one that jumped out at me was:

 

 

 

File: "C:\Documents and Settings\userID\Application Data\Microsoft\Outlook\outcmd.dat":

 

can't read security information, error -1020 (sharing violation)

 

 

 

As noted before, I *don't* see that error if I'm logged in with my admin-level userID and Retrospect Launcher is also set to run with the same userID & password.

Share this post


Link to post
Share on other sites

I have had a different problem with Outlook automatically closing. When Retrospect 6.0 re-starts Outlook, my custom toolbar settings are not present, and Outlook no longer loads my signature. The fix so far is to immediately close Outlook and re-start it manually.

 

 

 

Anyone have any idea of how to fix this, or maybe at least some idea of why this happens?

Share this post


Link to post
Share on other sites

PaulB-

 

 

 

I'm not even close to a Retrospect expert...but since no one else has answered...and since this is a problem I also have but think I know the answer...and although this is a bit off-topic for this thread...and a good moderator would suggest you repost in a new thread...and maybe you already have...

 

 

 

...and that's enough phrases conjoined by ellipses for a lifetime, don't you think...

 

 

 

My suspicion is that you're using Windows NT4, 2000 or XP. In these operating systems, Retrospect unattended backups run under "SYSTEM" credentials (if NT4) or "LocalSystem" (if Win2K or XP...same credentials, different name). This is a *different* user account than whatever your user name is. Even if you don't think you have a user name, you actually do, likely 'Owner' or 'Administrator' depending on the version of Windows.

 

 

 

In NT4/2K/XP, each user (including SYSTEM/LocalSystem) has their own settings, which includes toolbar customizations, etc. SYSTEM/LocalSystem can *stop* tasks under anyone's credentials, including yours. But it can't *start* tasks under any credentials but its own. This is a limitation of Windows, but surprisingly, it's a good limitation...it helps protect your computer and its data from bad guys on the Internet.

 

 

 

When Retrospect restarts Outlook, it does so under SYSTEM/LocalSystem credentials instead of yours. Since each user has their own settings, Outlook obediently shows you SYSTEM/LocalSystem's customizations and data instead of yours. Needless to say (and as you've observed), that's not real useful!

 

 

 

I *really* like that Retrospect can STOP Outlook before the backup. But I wish they'd make RESTARTING it a separate option. Because of the aforementioned security issue, Retrospect will not be able to restart it properly. It's easy to change the configuration for Retrospect to run under your credentials instead of SYSTEM/LocalSystem, but I don't know what the ramifications are, nor have I seen a Dantz KB article document this, so I'm not going to give you potentially bad advice by suggesting it.

 

 

 

The only guaranteed 'fix' is to downgrade to Windows 95, 98 or XP, but I wouldn't wish that on my worst enemy.

 

 

 

My only recommendation is probably not what you want to hear: Close Outlook some time before the backup. That's what I do.

 

 

 

Hope this helps!

Share this post


Link to post
Share on other sites

My bad...it's precisely on-topic. Had another IE window open on another thread and...

 

 

 

Never mind. It's been a looooong day!

Share this post


Link to post
Share on other sites

I was wondering about a variation of this.

 

 

 

Right now I auto-launch RP6 & RP5.6 (Retrospect Launcher) with my admin-level account ("Admin" for reference purposes) permissions. This Admin account is also on my other PCs (all XP or W2K), allowing me to access administrative shares (e.g. C$, D$) over my LAN *and* allowing RP6 to access those shares as a place to save backed up files.

 

 

 

I reported the issue (LocalSystem vs. Admin account fails to start & restart Outlook) with RP6 and Outlook a while ago (haven't paid attention to see whether a recent RDU had fixed it). I was wondering what would happen if I set up a separate admin-level account, "Retro," on all my PCs just for use by the Retrospect Launcher? When RP6 auto-launched on a PC with the "Retro" account where "Admin" was already logged in and running Outlook, would "Retro" be able to backup Outlook files and/or shutdown and restart a copy of Outlook that was being run by "Admin??

 

 

Share this post


Link to post
Share on other sites

So I ran some experiments with:

 

 

 

- User logged in as "Admin" (admin-level account).

 

----- Running Outlook 2000 as the "Admin" user.

 

 

 

- Set Retrospect Launcher Service to launch as "Retro" (admin-level account).

 

 

 

----------------------------------------------------

 

 

 

RP6 (RDU 3.5) would launch at the expected time. It was able to force quit Outlook and run a backup of the C: drive. The first time RP6 ran, in the middle of the backup, I got a dialog asking for my MS Office disk (not ideal for unattended operation), presumably because it was setting up a new "Retro" Outlook user or Outlook feature for this user.

 

 

 

The second time I had RP6 autorun, it didn't ask for the MS Office disk. However, after force quitting RP6 and running the backup, up popped a "MS Outlook is out of memory" (as RP6 tried to relaunch Outlook) and Outlook didn't launch (note: task manager said that I had 334MB free on my 512M W2K system). I assume that the core issue is that RP6 was trying to relaunch Outlook under the "Retro" user ID, but there was no desktop I/F running since only "Admin" was logged in.

 

 

 

Recall that, when both running Outlook 2000 as "Admin" *and* setting Retrospect Launcher to be "Admin" (rather than "Retro" or "LocalSystem"), RP6 was able to quit Outlook, but the system gave an error message ("(X) Could not complete the operation because the service provider does not support it. [OK]") when RP6 tried to relaunch it after the backup. This still happens even with RDU 3.5.

 

 

 

I do think that the suggestion to allow the user to *only* quit Outlook but not relaunch it would be a good idea, and would solve (work around) a lot of the issues with RP6, Windows and assorted login IDs. RP6 just doesn't play nice with anything other than LocalSystem and it's not practical to run RP6 this way if you're backing up to drives on other servers.

 

 

 

This just summarizes the impact on the ability of Retrospect 6.0 (RDU 3.5) to deal with Outlook. I've put a couple of other observations below.

 

 

 

----------------------------------------------------

 

 

 

When running the Retrospect Launcher service under the "Retro" admin account while using the PC under the "Admin" account, RP6 behaved oddly. When I manually launched RP6, it would often be *very* slow (e.g. a minute) to remove the splash screen. And when I quit RP6, I would get a "The Retrospect Launcher service is not running" even though it *was* running--in the Task Manager "retrorun.exe" was running under the "Retro" ID while Retrospect 6.0 was being manually run and quit under the "Admin" ID. Apparently the "Admin" RP6 couldn't see or didn't understand the "Retro" retrorun.exe task. Reboots sometimes cleaned this up but it seemed to return after a couple of launches.

 

 

 

Note that the Retrospect Launcher account *must* be an Administrator-level account on the system where RP6 is running. A "Backup Users" account wasn't good enough under W2K, and it's not even an option under XP (Admin or Users only). Technically you can run a non-admin account (e.g. Backup Users) on another PC if that other PC is only being used as a place to save a backup file. But RP6 must be running at admin-level.

 

 

 

All in all, I'm back to running RP6 under the "normal" login ID on each PC where RP runs. I assume I'll get the same odd behavior if another ID is ever running, but I never run this way. RP6 does seem to run well (with no errors in the log) if the user quits all programs and logs out, so that RP6 is running at *whatever* ID with *no* other users logged in.

Share this post


Link to post
Share on other sites

I think your answer of "why" but no solution to "how to solve" is likely right on. I have a similar problem, I suspect. Auto closing Outlook is a great feature and appreciated. But the restart appears to cause problems.

 

I have a Windows XP client with Retro Pro 6.0, Outlook 2000, and PGP 8.0 installed and integrated into Outlook. I do not have the "Open File backup add on". On the nightly backup, Outlook gets closed as expected but then restarted almost immediately. Everytime it restarts, PGP's new user wizard dialog pops up wanting to register a new user and set its Public/Private keys. I suspect this is, as you state, Retrospect starting Outlook up in the "System" account instead of my (one and only defined) account. If I close PGP's windows and Outlook and restart, everything is fine.

 

Anyone from Dantz have a response yet? How does one prevent Outlook from being restarted?

Share this post


Link to post
Share on other sites

There are no configurable options to stop Outlook from being relaunched. It's a great idea - and it's been submitted as a feature request.

Share this post


Link to post
Share on other sites

We've been experiencing this problem in my office as well. I called Dantz tech support, and their response is: "We do not support PGP. Buy Open Files Backup add-on."

 

So, Outlook, being an extendable application via plug-ins, is supported, but there is no support (nor even acknowledgement) for Outlook plug-ins? Boo to Dantz. That is a mighty annoying policy, in my opinion.

 

Is there any way to change (or add to) the credentials under which the PGP plugin was installed to Outlook? Seems like it's going to be a difficult road to travel to get Dantz to work on this (because, hey, it's not their problem), and a work-around is needed.

Share this post


Link to post
Share on other sites

The Retrospect Client is running under the local system account. It is possible that PGP is being accessed under that account during the relaunch. If you can find the settings for PGP that are being accessed during the re-launch of Outlook, you may be able to make an adjustment to PGP.

 

Dantz offers the Open File add-on specifically for users who are in situations were closing Outlook is not an option.

Share this post


Link to post
Share on other sites

How about meeting us half-way and just providing an option to start or *not* restart Outlook? I'm OK with RP shutting down Outlook on a backup if needed, but all of these issues happen when RP tries to relaunch Outlook under the LocalSystem account.

 

Does this issue happen with RP6.5 which uses the LocalSystem account for the Retrospect Launcher but can be to set run the RP program itself with a specific user login. Is Outlook relauched under the LocalSystem account anyway?

Share this post


Link to post
Share on other sites

This is an interesting suggestion, and I can pass that onto development.

 

 

 

6.5 application can run under the currently logged in user or as a specific user, I do not know if that will effect this issue.

 

 

 

As far as the Retrospect Client, you would need to try changing the account that the client runs under (but this is not something we normally recommend).

 

 

 

You can take another approach: Retrospect can trigger an external script before and after a backup. In Retrospect 5.6 we included a script that could be used with the client or server to close Outlook. I have attached a copy to this post. You should be able to edit the functionality and use it as needed.

 

 

 

Filename: QuitOutlook VBS.zip

 

Tested with: Retrospect 5.6

 

 

 

This item has never been tested with Retrospect 6.0 or 6.5. Directions for using External Scripts can be found in the User's Guide.

Share this post


Link to post
Share on other sites

Retrospect has no business offerring an option to shut down Outlook, or any other appp. That's the user's responsibility, as it is the user's responsibility to manage the system so that Outlook, or some other app, does not get started whilst Retrospect is doing its thing.

 

Heck, if a user launches, say, Word whilst Retrospect is running and during the Word session (un)knowingly launches Outlook, it would be unreasonable for Retrospect to try to prevent that from happening or to continually monitor the whole system to see if Outlook, or other apps are started whilst Restrospect is running, that's the user's responsibility.

Share this post


Link to post
Share on other sites

That does raise an interesting point--why are we only picking on Outlook? The goal is to backup the user's data, and Retro was unable to do that for Outlook while it was running *or* unless Open File Backup was used. Since the OFB add-in is too expensive for many SOHO users they ran into the Quit & Restart permissions issue. But under XP we get defacto OFB using the XP-included "Shadow Volume Copy" so Outlook doesn't cause a problem on many newer systems. And the "Force Quit Outlook" option (which can be turned off manaully) doesn't even do its thing on an XP system (with SVC) regardless of whether it's enabled.

 

However, there are probably many other systems running non-XP and running programs other than Outlook where data can't be properly backed up when the programs are running. In the case of Outlook a user may appreciate the Force Quit option (which *can* be turned off) to make sure data is backed up. But maybe Dantz should have (should?) come with a more general solution. An example might be:

 

Default:

[] Force quit running programs when Retrospect runs

[x] Do not force quit programs when Retrospect runs

 

Exception list (does opposite of default]:

[ Outlook

MS Word

]

 

This would give the user control to decide if running programs should be forced to quit or not, balancing the goals of leaving running programs alone vs. having all data backed up. And Dantz wouldn't have to know or try to guess which programs should be left running or forced to quit.

Share this post


Link to post
Share on other sites

There are a number of issues, including:

 

1. What is a "backup"?

 

I consider a backup to a snapshot of the files in a system at a point in time. If users continue to run other programs while Retrospect is running, they get what they deserve.

 

2. What programs are running?

 

Most users do not know how to determine what programs are running.

Over time, they will learn to exit, or otherwise "pause", running programs before running Retrospect.

 

The best that Retrospect can do is, when possible, backup open files. Note that the Open File feature should be part of ALL versions of Retrospect, not a separate add-on.

 

3. If programs are left running, Retrospect cannot be expected to backup up a changing set of files, again, a backup is a snapshot at a point in time.

 

To take a simpler case. I use Eudora as my main mail program. If I happen to run Eudora while Retrospect is running, Retrospect would be able to backup most Eudora files even while Eudora is running, but, again, only at a particular point in time.

 

4. I find it sufficient to fend for myself. I disable Auto-Protect in Norton Auntie virus while Retrospect is running So far, the only errors I get during a backup are scanner related (and I'm not using the scanner during the backup). The Perflib* file gets regenerated every time I reboot, so it cannot matter much, if at all, that the file cannot be backed up. Looking at SmaPanel,ini, I'd guess that it matters not whether the latest version is backed up.

 

- 6/23/2003 20:00:37: Copying Microng (G:)

File "G:\WINNT\SYSTEM32\Perflib_Perfdata_414.dat": can't read, error -1020 (sharing violation)

6/23/2003 20:03:37: Snapshot stored, 43.1 MB

6/23/2003 20:03:41: Comparing Microng (G:)

File "G:\Program Files\EPSON\EPSON SMART PANEL for Scanner\SmaPanel.ini": different modify date/time (set: 6/23/2003 20:01:14, vol: 6/23/2003 20:03:56)

6/23/2003 20:04:03: 2 execution errors

Completed: 296 files, 30.0 MB, with 64% compression

Performance: 89.7 MB/minute (89.7 copy, 94.4 compare)

Duration: 00:03:25 (00:02:44 idle/loading/preparing)

 

5. Automatically shutting down ANY program is noned of Retrospect's business.

 

All sorts of add-ins could be running that start/stop Outlook, or any other program. I don't see it as practical for Retrospect to try to monitor this.

 

For example, suppose Outlook were shut dow, but for whatever reason, the user had a need to send email, or do whatever, during the backup? Retrospect sure better not prevent that from happening.

 

P.S. I've been rambling above whilst I download the huge update to Retro 6.5.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×