Jump to content

poorman

Members
  • Content count

    39
  • Joined

  • Last visited

Community Reputation

0 Neutral

About poorman

  • Rank
    Occasional Forum Poster
  1. I don't think Retrospect 7 directly supports waking the machine to run backups. (Fingers crossed for Retrospect 8...) You might be able to work around this by creating a scheduled task that has "Wake the computer to run this task" enabled and scheduling that task to run slightly before your scheduled backups. -- Pete
  2. I don't think the issue is with priority. The issue comes from the client only supporting connection from one server at a time, and a previous connection not being released correctly. When I've seen this it was usually because the the server crashed during the backup. Disabling/re-enabling or rebooting resets the client so that it will once again accept connections from the server. -- Pete
  3. I've seen this occasionally (on versions prior to 7.7 -- I don't use 7.7 yet.) I've been able to correct it by either: disabling and then reenabling the client through the Retrospect Control Panel on the client machine, rebooting the client machine. You'd think that the Retrospect client would automatically reset itself if there has been no data traffic for an extended period, but it doesn't seem to do so. -- Pete
  4. poorman

    Scheduled Backup Stall

    The reference to open file backup in the error message makes me suspect that something is amiss with the Windows shadow copy capability on the client machine. I'm no expert on diagnosing and fixing shadow copy, but google finds quite a few threads such as this one that discuss it. There's a command line utility named "vssadmin" that displays the current state of the shadow copy subsystem. The common theme seems to be that if some of the "vssadmin list" commands hang or fail then there's something you need to fix. Also, there were a few threads on this topic in the old Retrospect report forum. For example, searching for "vssadmin retrospect" found this thread that might help. -- Pete
  5. Elaborating on Mayoff's terse reply... The Retrospect Launcher is a Windows Service that launches the main Retrospect application (if it's not already running) when it's time to run a scheduled backup. On Windows XP the instance of the main Retrospect application that is started by the Launcher will be visible to a logged-in user, just as if they had started it from the Start menu. On Windows Vista or Windows 7, however, the Launcher-initiated instance of Retrospect will not be visible to a logged-in user. This is due to an explicitly-made change to Windows starting in Vista. (See the MSDN article for details.) The purpose of the change is to increase security, however it requires rearchitecting of programs like Retrospect that rely upon a service-initiated process interacting with logged-in interative users. Retrospect has not yet been fully rearchitected to accomodate this change. (This will, presumably, happen in Retrospect 8.) Instead, a separate program called the Retrospect Activity Monitor provides a limited ability to interact with the otherwise-invisible instances of Retrospect that are started by the Launcher. Unfortunately, the Process Monitor does not work for many users. This seems to be most common on 64-bit systems. It is not clear to me whether or not this issue has been addressed in the latest version of Retrospect 7.7. -- Pete
  6. poorman

    Retrospect Not Running Scheduled Jobs Under Windows 7

    Glad it worked for you. Thanks for confirming my understanding of how Retrospect works. Roxio, a Knowledge Base article on this would be a good thing. -- Pete
  7. poorman

    Retrospect Not Running Scheduled Jobs Under Windows 7

    Retrospect hasn't been completely updated to work well with some of the security features that were added in Windows Vista (and are still present in Windows 7.) As a result, when the main Retrospect application is started by the Launcher service it can't communicate with your screen/keyboard/mouse. As in interim, there is a "Retrospect Activity Monitor" program to provide a view of what the (invisible) background instance of Retrospect is doing. Unfortunately, the Activity Monitor doesn't work for many people (including me.) It just shows a blank screen. There was much discussion about this in the predecessor forums. It seemed that most people who had trouble were running 64-bit Windows. I don't think anyone ever identified a fix. If you're one of the unfortunate people then about all you can do is try hard to configure Retrospect so that it never needs human interaction during scheduled backup. It may be, therefore, that Retrospect is in fact being started but you just can't see it. You can check using the Task Manager. Schedule a backup, then exit Retrospect. Wait until the backup should be running. Open Task Manager, go to the Processes tab, click the "Show processes from all users" button, and look for "Retrospect" in the Image Name column. If Retrospect doesn't show in the Task Manager then in may have failed to start. Another impact of Retrospect's incomplete adaption for Windows Vista/7 is that in some cases the Launcher will silently fail to start the main application. The workaround for this is to set Retrospect preferences to run "As the logged-in user". Confusingly, this doesn't necessarily mean the user that's logged in at the screen/keyboard. Rather, it means that the main Retrospect application should use the same login credentials as the process that starts it. If you start it from the Start menu then that's your login. If it is started by the Launcher then that's the credentials of the Launcher process, which are normally the special "Local System" account. Running as Local System is often just fine. It causes trouble, however, if Retrospect needs to access network shares such as those on a NAS box. For data sources you can set a user ID and password within Retrospect, which should be sufficient. A simpler and (possibly) more effective solution, however, is to configure the Launcher service to use a user ID and password for an account that has access to those shares. That way the Launcher will start the main application with those credentials, enabling it to access the network shares. The ultimate fix for these issues of compatibility with Windows Vista/7 security features is a refactoring of Retrospect to have separate processes for the the user interface and the backup engine. That's been promised for a future major release. (That promise was pre-Roxio, but I'm still hopeful.) In the interim, it would help tremendously if Roxio were to provide documentation that described how to effectively use Retrospect 7.x on Windows 7. -- Pete
  8. poorman

    Speeding up snapshots?

    Multi-tasking, yes. That's probably actually part of the cause of the "freezes". It's easy for several processes running in a system to get into a fight over the position of the heads in a system with a single hard disk. Head positioning is extremely slow compared to just about anything else in a modern PC, and the tasks all end up waiting for it. Laptops usually only have one disk, and those disks positions the heads slowly to reduce power consumption. -- Pete
  9. Another thing to try is to drag-and-drop the fine into Retrospect. -- Pete
  10. poorman

    Scanning incomplete, error -1010 ( API request bad)

    Another option is Microsoft Security Essentials. I'm running Retrospect 7.6 with it without issues. Security Essentials is also free. -- Pete
  11. poorman

    Version 7.7 locked range conflict on pst file

    My apologies -- I thought we were talking about the Retrospect Client, not the server. The server has a preference for which user ID it will run under. It defaults to running as the "currently logged in user." This means your login ID when you run Retrospect interactively, and the login ID of the Retrospect Launcher service when Retrospect is launched automatically. The Launcher Service defaults to running in the Local System account, so background/automatic executions of Retrospect normally run in Local System. It's possible to select other values in the Retrospect preferences, such as an explicit login ID (with password). That may work well on XP, however on Vista and Windows 7 it causes several kinds of grief. On those OSes you may have better results with it set to "currently logged in user" and instead change the ID that is used by the Retrospect Launcher service. I hope this helps. It seems likely, however, that there is a more general problem with Open File Backup in Retrospect 7.7, as another user just posted about doing a 7.6->7.7 upgrade and immediately having the locking-range-conflict issue. -- Pete
  12. poorman

    Version 7.7 locked range conflict on pst file

    Thanks for reporting on the results of your re-test. Are you sure that the Retrospect Client actually runs as your user ID? I'm pretty sure that the Retrospect 7.6 client runs on the Local System account. The default ACLs allow the Local System account to have full access to just about everything. If those ACLs have been changed then I suspect that most backup programs will have trouble. -- Pete
  13. poorman

    Version 7.7 locked range conflict on pst file

    You can see the user ID that the client is running under in the Processes tab of Windows Task Manager. (You'll have to show processes from all users, of course.) It's probably one of the special IDs such as LOCAL SERVICE. Then open the properties of the PST file, go to the Security tab, and see if that user ID has (at least) all the Read permissions. The easiest way to check the permissions is probably to click the "Advanced" button, go to the "Effective Permissions" tab, and select the User ID that the client is using. If that ID doesn't have read permissions then your system probably has some nonstandard access controls on that drive or its subfolders that prevent the Retrospect Client from accessing the files. -- Pete
  14. poorman

    Retrospect 7.7.208 released

    Thanks Robin. Please thank the development team as well. Is there a way to access a longer description of each fixed issue? The release notes have a number by each issue, but searching the KB for those numbers doesn't find anything except the release notes. -- Pete
  15. poorman

    Scripted Backup Will Not Wake Computer

    It seems clear that while Retrospect 7.7 will use wake-on-LAN to wake up clients, it simply isn't designed to wake the server machine for scheduled backups. It appears that Windows 7 Task Scheduler can do the job. I created a basic task on a test machine (which is running Windows 7 RC) and modified the task's properties to enable it to wake the machine. The machine woke up at the scheduled time. So, if you created one or more scheduled tasks on your Retrospect server to wake you machine a few minutes before each scheduled backup then Retrospect will probably run as you desire. If you try this please do report back on this thread so we all can learn from your experience. -- Pete
×