Thanks Robert!
c) Microsoft introduces some new security kink, that breaks interaction between services or interactions with vss. Yes, those VSS issues still occur at times Regards -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Robert A. Clark Sent: Thursday, November 17, 2011 12:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Windows 2008 client ..TSM schedule won't run On Windows, the real details of the client configuration is comprised of: 1) The information in dsm.opt 2) The information stored in the services config and returned by 'dsmcutil list' and 'dsmcutil query /name:"service name"'. 3) Other registry stuff. 4) Unknown magic windows security stuff. 5) Client option files from the server. There are a few recurring types of breakage: a) New client setup wizard is broken in some obscure way. b) Human typo somewhere during the client setup wizard. c) Microsoft introduces some new security kink, that breaks interaction between services or interactions with vss. d) Client upgrade without all the services being stopped first. e) Human intuition fail on some basic part of the client config. f) Machine P2V'd or migrated without letting the TSM admin know. In my experience, the most productive troubleshooting methods for most of these situations: Make sure the basic client requirement (like hotfixes on W2K3 SP2) are met. (Duplex settings?) If the client broke after a round of OS patching, look into a more current client version. Look at the logs. Look over the dsmcutil output. Ask a second set of eyes to look for config typos. Write a simple batch file to uninstall the client services. Write a simple batch file to install the services. Confirm the uninstall/install set things up properly. <= This fixes 80% of common config problems. If the client language catalog is corrupted, run a fix install. Make sure scheduled defrag and backup aren't running at the same time. Only one vss snapshot can be in process at a time, and nothing smart is automatically done to coordinate this. Run a search on the support site to be sure it isn't a known problem. Check with ADSM-L. [RC] timothy.hug...@oit.state.nj.us Sent by: ADSM-L@VM.MARIST.EDU 11/17/2011 07:19 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Windows 2008 client ..TSM schedule won't run Thanks Richard! No changes were made to the cad and define Association is in place. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Sims Sent: Wednesday, November 16, 2011 4:04 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Windows 2008 client ..TSM schedule won't run On Nov 16, 2011, at 2:54 PM, Hughes, Timothy wrote: > Thanks Al > > No, there no entries in the scheduler log (or dsmerror logs) The schedule log is just shows the schedule is ready to start but it doesn't. Not familiar with the "power settings'? I will have to check with the Windows Admin for that. Presumably, then, this schedule is not run under CAD, and thus the client option MANAGEDServices is not in play, and thus no dsmwebcl.log to be examined. Your next step, then, is to examine the TSM server Activity Log for evidence of issues. And, obviously, assure that DEFine ASSOCiation is in place for that node to participate in a schedule. If options changes were made with the dsmc schedule process in existence, it would need to be restarted for the new values to be in effect. Whereas Prompted mode is in effect, you can telnet to the client 1501 port, whereupon the telnet should just sit there if the service is healthy. Richard Sims If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.