Jump to content

jdbausch

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jdbausch

  • Rank
    Occasional forum poster
  1. Mayoff, thanks for posting on this issue. to be clear, this config DID work before I put the 2003 sp 2 on the system. so to answer your question, that is the config I was running, and it did work for me , BEFORE I put the 2003 sp 2 on the system. since then I have the grayed out - non functional - retrospect in remote desktop sessions. it works fine logged on locally. thanks
  2. I'm having the issue mentioned below: grayed out client under remote desktop after service pack 2 on windows 2003 server. (this is a 64 bit OS on the server) I've implemented the fix listed below - adjusting the permissions. Removing existing permissions, adding system and administrators. (forced them all the way down) I have no idea what this RBU mentioned account is. this server is a domain member, but I've searched anywhere, and I can't find any such an account. I'm still having the same problem. Does anyone have any suggestions? having to work for the console is totally bush league. _______________________________________________________ http://kb.dantz.com/display/2n/index.asp?c=&cpc=&cid=&cat=&catURL=&r=0.1759149 TITLE: Updating to Windows 2003 SP2 and Remote Desktop Discussion After upgrading to Windows 2003 Server service pack 2 from a prior service pack users are no longer able to access Retrospect via Remote Desktop. The GUI is grayed out and unusable. Some users have also been forced to re-enter Retrospect license codes when launching Retrospect. The service pack upgrade has incorrectly changed the permissions on the Retrospect configuration folder to "Everyone: Full Control". A service pack upgrade should not be changing the permissions of a Retrospect folder. Resolution for Remote Desktop Issue: Change permissions on C:\Documents and Settings\All Users\Application Data\Retrospect to: 1. Remove Everyone 2. Add Administrators: Full Control 3. Add SYSTEM: Full Control 4. Add RBU: Full Control (this may only be necessary in a domain configuration) Resolution for License Code request: Restore an older copy of your config75.dat file to C:\Documents and Settings\All Users\Application Data\Retrospect _________________________________________________________
  3. we run retrospect multiserver 7.5 I need to get more capacity, and quicker backups, so I'm thinking of adding a second tape backup device questions: can retrospect backup to 2 tape drives simultaneously? (I'm guessing yes...) is this supported with the software I already own (meaning do I need to purchase any more retrospect software/licenses to allow this?) thank you
  4. that caused it to start - but I have a couple of more questions now... when no one is logged in on the server, it runs, which is good. However, once logged in, I launched the retrospect console to check the status of the backup - and it stopped the current script... ? is this the way it is supposed to work? Maybe there is a configuration option that I should have different? if this is 'correct' is there a way to monitor a processing backup that is running in this way? sorry for all the questions, I'm still trying to figure this whole product out... and thanks!
  5. thanks for that - I'll give it a try tonight.
  6. Forgive me if this is a "dumb" question, but I am new to retrospect we have a multi server 7.5.370 installation running on a 64 bit windows 2003 server. I don't know how long it has been running - I'm new here Jobs (scripts -actual backup events - whatever they are called) will not start UNLESS you have the server logged in AND the console running (the retrospect application) I checked under preferences, execution, startup, and it has the following settings: (check) enable retrospect launcher service (check) automatically launch retrospect (radio button selected) stay in retrospect (check) show taskbar icon so to me it looks like the backups should run, even if there is no-one logged into the server - but this does not appear to be the case. Any help would be appreciated, as this is obviously not a great way to run for us.
×