On 23.09.2011 14:46, Jeffrey Altman wrote: > On 9/23/2011 3:00 AM, Lars Schimmer wrote: >> Hello >> >> I experienced some heavy problems with deinstalling the 64bit package of >> OpenAFS 1.5.x on our windows 7 workstations. >> >> While/after deinstalling the 64bit package (MSI) of OpenAFS 3 (out of 6 >> I tried) workstations did no more accept any admin user as >> administrator, the service to start the services did not start and >> furtheron I can onl reinstall complete system to get it working again as >> I do not obtain any right to administrate the system or start any >> servive => I cannot deinstall/install any software, I cannot remove it >> from the domain, I can just logon/logoff and copy data to/from harddrive). >> >> Has anyone experienced and similar? >> >> (the workstations were setup in last/this year, are in a domain, >> upgrading OpenAFS did worked well on them, I was login as a local >> administrator while deinstalling the OpenAFS 64 MSI package,...). >> >> Somehow it looks like the registry is destroyed in a very bad manner. >> And this has happen on 3 workstations yet (out of 6 I tried to deinstall >> OpenAFS 1.5.x for installing 1.7). >> >> >> MfG, >> Lars Schimmer > > Lars: > > While your situation sounds horrible I have a hard time believing it is > the result of OpenAFS itself being uninstalled. If that were the case I > would run into the problem on a consistent basis as I switch between > release series. OpenAFS does not add itself as a dependency for other > services.
I am sure OpenAFS is not the root cause for this situation. But as it happend 3 time at OpenAFS deinstallation it somehow is involved. But I do not know in which way. > My guess is that one of two things are true: > > a. the local administrator account has somehow obtained a dependency on > the \\AFS name space perhaps with an auto-run or other and as a result > will not start because after OpenAFS is removed there is no method of > accessing the dependency. It had Z: and Y: mounted to \\AFS\cgv.tugraz.at, but system profile is located on local harddrive. No dependancy on Z:\ and Y:\ is known to me. On other workstations with same setup nothing bad happend while deinstallation with Z:\ and Y:\ still being mapped. > b. your machines have a rootkit or other damage and the removal of > OpenAFS is triggering bad behavior. Rootkit could be, as machines are in a room for work with students. Need to check. The latter seems to be the case, though I do not know the real reason (some software installed, not have had problems yet). > The 1.5 series does not have any kernel component and is not capable of > altering the role of administrative bits. > I would start by examining the registry for dependencies on \\AFS. For > example, are there any system drive mappings to \\AFS that would be > persisted? Any service application paths that refer to \\AFS or a > mapped drive letter? Etc. Would love to, but I cannot as easy yet. I can login as a admin account, but all action requiering rights as admin, I/system cannot perform. On control panel it writes: "the dependancy service or group failed to start", on login the error "C:\Windows\system32\config\systemprofile\desktop refers to a location that is unavailable" appears and I cannot go into it, as I got no admin rights. I cannot view system messages/logs, to. And even booted in safe mode the same errors do appear. But as I do miss some knowledge and time I will check for rootkits and some obvious other errors and later on redo system and better check other workstation ahead of making changes. > Jeffrey Altman > MfG, Lars Schimmer -- ------------------------------------------------------------- TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [email protected] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
