On 9/23/2011 8:48 AM, Lars Schimmer wrote:
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.
Googled for: Desktop C:\Windows\System32\config\systemprofile
Shows this is a know problem for example:
http://forums.techguy.org/windows-vista/808717-solved-c-windows-system32-config.html
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
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
