Showing posts with label administrator. Show all posts
Showing posts with label administrator. Show all posts

Sunday, April 1, 2012

Windows 7: Deleting Excess "User" Accounts

One day, while wandering through the forest of drive C, I came upon C:\Users, where I beheld more users than I had anticipated. We had Administrator, All Users, Default, Default User, Public, Ray, and Ray Woodcock.  Who were all these people?  And did I want to be associated with them?

Most of these weren't listed in Control Panel > User Accounts > Manage another account.  There, I saw only Ray and Guest.  (I had set myself to be Administrator.)  Guest wasn't listed in C:\Users, so there seemed to be some slippage here. Maybe Guest didn't actually exist yet; the button was there just so I could add a guest account when needed.  So were all these Users in C:\Users real?  Could I delete any of them?

This appeared not to be exactly the same as deleting an account that would appear in User Accounts.  Here in C:\Users, I was dealing with folders that looked like they were tied in with other things.  In other words, it seemed that it could be a bad idea to delete the wrong account.  I ran a search, seeking guidance, but even Microsoft seemed pretty blasé about the prospect:  "If you have a user account on your computer that is not being used, you can permanently remove it by deleting it."  Period.  Just do it.  There were different steps, they said, according to whether the computer was on a workgroup or a domain.  Their procedure for making that determination was (in my translation) to go to Start > Run > SystemPropertiesAdvanced.exe > Computer Name tab.  (Soon, I would run into stories of grief from those who had actually proceeded to wipe out their C:\Users subfolders willy-nilly.)

Back in C:\Users, I went into the Administrator folder.  The only thing there was a subfolder called Application Data\ImgBurn\Log Files.  Well.  Could I set ImgBurn to put its log files somewhere else?  It seemed I could.  The relevant settings were in ImgBurn > Tools > Settings > File Locations tab.  There were actually four different folders that I needed to create elsewhere, in order to completely eliminate ImgBurn's need for C:\Users\Administrator.  I saved the ImgBurn Settings.ini file so that I wouldn't have to do this again after some future installation.  Then I deleted that folder.

Next, I went into C:\Users\Ray Woodcock.  This one had evidently been created by Microsoft Office, for the use of Outlook.  But I wasn't using Outlook.  So I just deleted C:\Users\Ray Woodcock.

The list was getting shorter, but now the sledding was tougher.  I wasn't going to delete the Ray account.  Two of the four others -- All Users and Default User -- had padlock icons, suggesting that Windows would rather keep them.  All four also had lots of subfolders.  It appeared they might not meet the Microsoft qualification:  IF the account is not being used.  These accounts were not being used by me, directly.  But it appeared that someone was using them.

I tried a search for the Public account.  I ran pretty quickly into advice not to delete that folder, and a cry for help from someone who had done so.  End of story on that.

Well, how about the (padlocked) All Users folder?  For that, a search yielded the information that C:\Users\All Users was just a symbolic link to C:\ProgramData.  I attempted to check this.  Yes, both folders did seem to contain the same subfolders, apparently used by a variety of programs:  Adobe, Apple, Skype, etc.  The status bar at the bottom of Windows Explorer said there were 26 items in each.  It seemed that the All Users folder was there for backward compatibility with programs that would look for it instead of for C:\ProgramData.  In short, I could make things difficult by deleting it, and it seemed that deleting it wouldn't actually have anything to do with any real accounts.

This left me with the Default and Default User folders in C:\Users.  I didn't understand the difference between these two, so I ran a search.  MrBruce1959 said that Default was a system folder, not to be toyed with, whereas Default User was supposed to be the initial or default account for the person who would be using the computer.  In that case, I didn't understand why Windows created a separate Ray account (my choice of name, their choice of folder) instead of renaming Default User to be Ray when I was first setting up the system.  Why leave a superfluous Default User folder after the real default user has made an appearance? 

I tried a different searchSomeone passed along the rumor that I could just go ahead and delete the Default User folder.  Another post spoke blithely of deleting the Default User folder (actually, they said "profile," not folder) with a script, so as to replace it with a preconfigured Default User replacement.  That one was followed (at the bottom of the Experts Exchange page) with an extended discussion of programming technique, so apparently it was OK in principle to delete the folder, at least if a look-alike then took its place.  A post in another thread said that Default User was the one from which other user profiles were built.  I didn't plan on letting anyone else into my world, so I felt I could do without it for that purpose.

I decided to zip the Default User folder, delete it, and save the ZIP for future reference.  Before doing this, I made a System Restore backup (Start > Run > SystemPropertiesProtection.exe).  Also, since System Restore had been flaky sometimes in the past, I made an Acronis drive image.  I gave this some time, to see whether it would have adverse effects.  A couple of days later, the system seemed to be running OK.  The removal of the Default User folder did not seem to have any immediate or obvious negative effects.

Friday, March 9, 2012

Windows 7: "Access Denied" on the Command Line When Using FIND

I tried to run a FIND command in the CMD (sometimes called the DOS) box in Windows 7.  I got an error message:

Access Denied - D:\FOLDER\SUB FOLDER
This was bizarre.  I had been using the command line in this Win7 installation for months.  Well, something had apparently changed.  I got this message regardless of whether I used my pre-installed "Open Command Window Here" right-click option in Windows Explorer or the Administrator Command Box option I had created in the Start menu.

A search led me through various possible solutions.  I tried especially to tweak the permissions for the entire partition and for the individual folder via right-click > Properties > Security tab > Advanced > Owner tab > Edit > select Administrators and check "Replace owner on subcontainers and objects," and to play with other tabs and settings in that vicinity.

One option I hadn't seen previously was to open the Local Group Policy Editor (Start > Run > gpedit.msc) and go into Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > right-click on "User Account Control:  Behavior of the elevation prompt for administrators in Admin Approval Mode" > Properties > Elevate Without Prompting.  But I already had that selected.

That writeup raised the question, though:  had I not completely disabled User Account Control (UAC)?  As advised, I went into Start > Run > Regedit and navigated to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System.  There, I right-clicked on EnableLUA and verified that the value was zero.  Nonetheless, I exported the tweak, extracted the relevant lines from the REG file, and added them to my Win7RegEdit.reg file for future installations, just to be sure.

When I was in Permissions (via Windows Explorer folder right-click > Properties > Security tab > Edit), I noticed that the permissions checkboxes were checked but greyed out.  I couldn't change them.  Was I somehow not in the right account?  A search led to a proffered batch file (Permissions.zip) that read as follows:
@echo off
title File/Folder Permissions
echo.
echo.             BY KAOS - Windows 7 Forums
echo.
echo.
set /p a=Enter Path Of File/Folder:
echo.
set /p b=User Name:
echo Type "deny" = remove access OR type "grant" = allow full access
set /p c=Permission Type:
echo.
echo.
echo.
if %c%==deny goto lock
if %c%==grant goto unlock
if %a%==menu goto start2
if %b%==menu goto start2
if %c%==menu goto start2
:lock
cacls %a% /e /d %b%
cls
exit
:unlock
cacls %a% /e /g %b%:f
cls
The gist of this batch file seemed to be that I could try a CACLS command of this form:  cacls [folder path] /e /g [username]:f, where /e meant "edit," /g specified the user, and :f gave full control.  So, in my case, what username would I use?  Control Panel > User Accounts said that I had set up my system so that the only options were Ray (Administrator) and Guest (turned off).  Maybe this was the problem:  I had been thinking in terms of the Administrator account rather than the Ray account.  So, OK, I tried typing this on the command line, to grant full control to the whole drive:
cacls D:\ /e /g Ray:f
In response to that command, I got a short message:  "processed dir: D:\.  Did that mean champagne?  I retried the command that had given me the "Access Denied" error.  No, still denied.  Alright, how about same command, different user:  Administrator.  Same output.  Still denied.  Baffling!

I ran across a post that said something about turning off simple file sharing and permissions, and then permissions.  It raised a question:  was there a way to reset permissions to the default, and start over?  For the drive (i.e., right-clicking on D: in Windows Explorer), I went into Share with > Advanced sharing > Sharing tab > Advanced Sharing.  I unclicked Share This Folder > Apply.  I got a note indicating that I had some files currently opened, and they would be closed.  I clicked Yes > OK > Close.  This, in itself, didn't have any effect on another try of the FIND command; still denied. 

I had recently gotten an indication that the Recycle Bin on drive D was corrupted.  I had said go ahead and empty it.  That message had recurred.  I had also been getting bothersome messages when I tried to move or delete folders, telling me that these folders were shared and confirming that I really wanted to do what I had said I wanted to do.  It seemed that these problems might be related.  But how, and what could I do about it?

I found a Windows XP article from 2002 that said, "If you don't have a thorough understanding of the various permissions and their relationships, it can be nearly impossible to sort out a permission problem and find a solution."  So I could see how Windows 7 was a direct descendant from Windows XP:  both could make it impossible to get any work done.  The article said that there was a difference between sharing permissions and NTFS permissions, and that the more restrictive one wins.  So if I wanted to grant full control to everyone for everything, I had to do that in two different right-click > Properties tabs:  the Sharing tab and also the Security tab.  But it really looked like I had done that, over and over again.

Ah, but now I saw a new problem.  In the Security tab, I saw that I had a little red circle with an X in it, next to the Administrator group.  There was no right-click option to explain it.  I guessed that the problem was that I had entered the wrong CACLS command, regarding Administrator rather than Administrators (plural).  So that was interesting.  I clicked on Edit, selected Administrator, and clicked Remove.  Then I re-ran that CACLS command with a reference to Administrators, this time, instead of Administrator.  But still no joy on my FIND command:  Access denied.

So anyway, as I was saying, it did seem that I had given full control to almost everyone listed in the Security tab.  I mean, literally, Everyone:  I had an entry for them, and they had full control, and so did SYSTEM, Ray, and Administrators.  But not Authenticated Users, and not plain old Users.  Who the hell were all these people, anyway, and why did we all need to have so many kinds of access to my computer so that I could get work done?  (Sigh.)  Wiser minds knew; I did not.  Anyway, I went ahead and gave full control to my whole world to everyone and his brother, Users and all.  And still the godforsaken command did not run.

And, by the way, at this point I searched in vain for those greyed-out permissions boxes I had seen earlier.  Evidently I had altered something significant, in all this screwing around.  Not so significant as to actually let me get any work done, but significant certainly in the sense that I could no longer detect greyness when I searched therefor.  Not in the Security, nor back in the Sharing tab.  Speaking of which, I now saw that my reestablished share of drive D now had permissions only for Everyone.  Did Everyone include me and all the other Administrators and Users and Authenticated Users of my home system (I was living alone), or did I need to add the whole gang back to my computer?  Not sure.

It occurred to me that I did have a solution.  It was called System Restore.  But, alas, the mere fact of telling Windows to keep system restores, accompanied by weekly checking to make sure that the task was really running as scheduled, did not necessarily mean that I would actually have recourse to any system restore points, other than the one created that very morning.  Apparently Windows was not content with the 10GB of disk space I had set aside for this purpose.  Fortuitously, I did have an Acronis drive image from a week or so earlier, and so, without further ado, I wiped the drive and restored that.  Did there exist any further difficulty?  Yes, there did.  My Acronis backup was too recent.  Apparently this problem had lurked for days and/or was not only, or primarily, a matter of drive C (stored in Acronis) as distinct from drive D (not backed up in Acronis).

I tried a different command that, I knew, I had run within recent days:  DIR.  It ran.  Now, why would DIR run and FIND not run?  FIND took a look inside files; were my permissions of some type not reaching into the files?  I right-clicked on the files in question.  They didn't have sharing or security options collectively; I had to click them one at a time to get a Security tab.  It said everyone had full control.  The Advanced > Owner tab option said the owner of at least one file was Administrators.  Anyway, the CACLS command was supposed to take care of user accouint issues.

I tried the same FIND command on another computer of virtually identical configuration.  It, too, provided a FIND error.  A search led to a brilliant insight:  my command was wrong.  I was trying to use FIND on a directory, when it only works on files.  I had to make one change:  I had to add a star (asterisk) to the end of my search.  The FIND command worked without error when I did it this way:
find /i /c "X-Message-Delivery:" "D:\Folder\Sub Folder\*"
Solution:  operator error.  Case closed.

Saturday, May 14, 2011

ASUS Eee PC: Windows 7, Acronis True Image Universal Restore, and Partitions

I put my laptop up for sale and got an ASUS Eee PC 1215T-MU17-SL.  Got it on sale for $359, reasoning that if inflation kicked in and/or the Japanese earthquake/tsunami damage affected equipment production, prices may not continue to drop as rapidly as they have in recent years.  Operationally speaking, the theory, not yet tested, was that I would be able to go running with this in my Deuter Speed Lite 20 backpack, and then just sit down and go to work, out in the woods or wherever.

First, I had to configure the Eee the way I wanted it.  Its hard drive, at around 300GB formatted, was big enough for a lot of material, but they had devoted 100GB to the Win7 Home Premium partition.  Then there was another 15GB partition, apparently containing a backup of the original Win7 installation, as well as a tiny program partition at the end.  It seemed advisable to squeeze out some disk space, if possible.

My plan for disk space was to start with a backup of the existing program partition, copied to an external USB drive in case everything went south.  I used Acronis True Image for this purpose.  I was able to get Acronis loaded onto a USB flash drive, which was necessary since (a) the Eee didn't have a CD/DVD drive and (b) I didn't have an external USB CD/DVD drive to connect to it.  I wasn't taking notes at the time, but in my recollection the process I used to get Acronis onto the thumb drive was, first, to install Acronis on a desktop and then use that program's Bootable Rescue Media Builder to install the program onto the USB drive.  If I hadn't already bought Acronis, I probably would have started with a highly rated freeware imaging program.  CNET listed several -- Easeus Todo, Macrium Reflect, and Paragon Backup & Recovery Advanced -- that would have been worth trying.  Getting them onto a USB drive might have entailed the use of Unetbootin or Universal USB Installer.  In all events, booting from a USB flash drive was a hassle:  the BIOS on the Eee would not reliably remember its previous settings, so that it was necessary to reset the BIOS to boot from the jump drive each time.  The essential first step, there, was to hold down F2 as soon as the machine started to boot.

I really wanted to move if not delete that 15GB original backup partition.  I'd be glad to keep an image of a virgin installation offline, on a hard drive on the desktop, where space was cheap; but in the field, if I was limited to one backup image, I'd prefer that it would be an image of the program drive in its current configuration.  In other words, if I had to restore Windows 7, I would ordinarily try first to restore from a drive image that included a fairly recent collection of the various programs and settings that I would be using from day to day.  And I wouldn't store this image in the middle of the hard drive; I'd put it on a partition at the end, where it would be out of the way.

I gathered, from various comments, that if you moved that backup partition, the machine would no longer be able to restore it quickly using the built-in backup setup.  I wasn't too concerned about that, but it was a thought to take into account.  I was also concerned that messing with the partitions would somehow invalidate the warranty.  I didn't explore that question extensively, but as far as I could tell at a brief glance, that was not the case.  So it seemed that I could go ahead and adjust the partitions to taste.

My first step, after making an image of the original installation, was to delete the drive C partition.  I did this with a copy of GParted, installed on a UHSB drive using Universal USB Installer (above).  That step gave me 100GB of unallocated space at the start of the drive.  Now, ideally, I would use the Universal Restore feature of Acronis Drive Image Plus Pack (my reason for buying an Acronis update) to restore a previous Windows 7 installation to what they called "dissimilar hardware."  That is, I wondered whether I could save myself a lot of program installation and tweaking time by restoring a copy of my desktop computer's Windows 7 installation to the Eee.  Apparently I'd have to either uninstall Win7 from the desktop or buy a second license if I wanted to use Win7 on both.  Either way, it seemed like it would be a lot easier to use the Acronis approach than to manually recreate all of the steps I had gone through to tweak my Win7 system the way I liked.  In my previous experiments with the Universal Restore capability, it had seemed that it would be crucial to obtain the drivers for the Eee's hard drive controller or chipset.  The Acronis procedure asked me whether I wanted to include such drivers but, alas, I was not able to detect exactly where the desired drivers were located.  I tried running the restore without them, but got this message:

Device driver 'PCI \VEN_1002&DEV_4391&SUBSYS_11171043&REV_00' for 'Windows 7' cannot be found.
The driver for the device cannot be found in the operating system or in the additionally specified drivers.
I tried searching my desktop computer and online for various forms of that specified driver, but no luck.   I clicked "Ignore" and got no further error messages, but also got a system that would not start.  It would get to the point of giving me a choice of booting into Safe Mode or Normal Mode, but neither went anywhere.  One problem was that I was working with current Eee drivers in the downloaded .exe format, whereas I was supposed to extract the .inf, .sys, or .oem drivers from those exes.  There seemed to be drivers for both the SATA and the chipset, with no explanation as to which I needed.  I decided to extract them both, put them into one folder on another USB drive, and let Acronis choose which one it needed.  But I really had no idea what to extract.  The SATA download, for instance, contained no files in any of those three formats.  It did contain two .cab files, but neither WinRAR nor 7zip was able to extract anything from them.  The Acronis forums seemed to contain a number of messages from frustrated users, but I thought I should probably post a question myself.  But I hated to burden the system with a question that had already been asked and answered, so I searched againOne thread advised that I should extract from the .exe, not from the .cab, so I tried that; but that, too, gave me the "not a supported archive" error in 7zip.  That was when I used the right-click 7zip option in Windows Explorer.  When I went at it from inside 7zip, the recommended "Open Inside" command did nothing.  Another post clarified that the single thing I most clearly needed was the driver for the hard drive controller -- but even then, it still sounded like I also needed chipset drivers.  HackerJoe in that same thread suggested that perhaps I should have installed the latest hard drive controller while I still had the system running, and then keep a copy of the C:\Windows\Inf folder and point Acronis to that.  Well, but at least I had an old copy of that folder, in the drive image that I had already made.  I hooked the backup drive to another computer, opened that image, and copied its C:\Windows\Inf folder to a new folder, INF, on the external drive.  I reconnected the external drive to the Eee, re-ran Acronis, pointed to that inf folder, and told it to restore both drive C and the MBR.  This time, it ended with a different error message:
File 'amdsata.sys', that is required for installation of device 'AMD SATA Controller (ID: AMD)' in Windows 7, cannot be found.
It seemed to me that this message should have come up during the first try, when I clicked "Ignore" instead of "Ignore All."  Anyway, a quick search on the desktop computer suggested that amdsata.sys came in different versions, but that for the last two years its size had not changed.  I added a copy of that file to the INF folder on the external USB drive and clicked Ignore.  Now I got another error:
File 'AtiPcie.sys', that is required for installation of device 'AMD PCI Express (3GIO) Filter Driver (ID: Advanced Micro Devices Inc)' in Windows 7, cannot be found.
I was grateful that, this time, I did get more than one error message, so as to remedy multiple problems before trying again.  On the other hand, I was concerned that a message relating to PCIE did not really seem to be relevant to the the hard disk controller -- that, in other words, the advice from Acronis to focus on the hard drive controller did not seem to cover the entire situation.  On the desktop machine, atipcie.sys was in C:\Windows\System32\drivers.  That was also where amdsata.sys (above) had been.  It seemed that I might be able to anticipate most if not all Universal Restore errors by adding the contents of that Drivers folder to the INF folder on the external drive.  I did that.  The INF folder now had 1,912 items, but they took only 146MB of disk space -- less, if I had deleted the subfolders contained within it, where I doubted the Acronis process would search.  Then it occurred to me that these desktop versions of these files -- of amdsata.sys, AtiPcie.sys, and so forth -- might not be what was needed on the Eee.  It seemed, in other words, that I should have copied C:\Windows\System32 from within the previous Acronis backup, not from the desktop.  So I went back, wiped out the INF folder, and did it over again, this time copying everything from the C:\Windows\Inf and C:\Windows\System32\drivers folders contained within the Acronis backup of the original Eee PC's drive C installation.

With that done, I clicked Ignore again. This time, it said, "Recover operation failed."  Before attempting another recover process, I tried booting the Eee in Safe Mode.  It got as far as listing AtiPcie.sys.  There, it stalled and, after a minute or so, it rebooted.  Seeing AtiPcie.sys at that location suggested that the list of .sys files shown when going into Safe Mode might be the complete list of what was needed in order to make the Acronis Universal Restore process work.  What I should have done, in that case, was to boot the Eee in Safe Mode in the first place (while I still had the original drive C partition), videotape the list of files that it was loading, and make sure those were present in the INF folder on the external drive.  But it seemed the list might change, and anyway it would take time to write it up and verify it, so I hoped this simple step of copying over these files from these folders would do the trick.  I went back into Acronis on the Eee, pointed toward the INF folder on the external drive as the source of drivers, and went through the steps of recovering the full Windows 7 installation from the desktop machine.  This time, I got "Recover operation succeeded" without any error messages.  So it appeared that the approach of pointing Acronis to a whole folder full of .inf and .sys files was on the right track.  I rebooted the Eee and got a "Starting Windows" screen.  Success!

Now there was a problem of making sure Windows 7 from the desktop was actually going to run.  It was trying to load all the things that the desktop version would load, and some of those were not relevant.  I restarted in Safe Mode by hitting F8 repeatedly as soon as it rebooted.  There, I went into Control Panel (using Small Icons, not Category view) and went into two different areas.  First, in Programs and Features, I uninstalled programs that I would not be using on the notebook (e.g., video editing).  Second, in Device Manager, I looked for inappropriate hardware.  The only item marked as dysfunctional was the ethernet device, probably because I had chosen Safe Mode without networking.  I rebooted into Normal Mode.  No, there was an Ethernet Controller problem here too.  I right-clicked and chose Uninstall.  Also, since there did not seem to be a need for the 15GB partition mentioned above, I went into GParted and deleted it, and also rearranged and added partitions as desired.  The desktop installation used one of these new partitions as drive X (called BACKROOM) to hold the paging file, caches, temporary internet files, and other items that did not need to be on drive C, where they would bloat any backup drive images I might make, so now I imitated that layout on the Eee.

Unfortunately, at this point I began running into problems.  It seems that my first step should have been to delete my user profile and create a new one, or perhaps to include some kind of generic or blank user profile before making the drive image that I was now restoring.  Win7 was trying to load all kinds of stuff that wasn't going to work, and many of its settings were wrong.  In both Normal and Safe modes, I wound up getting stymied by "Server execution failed" errors.  A search led to suggestions that the problem was due to the registry looking for partitions that did not yet exist -- that I had not yet had time to create or re-letter using diskmgmt.msc in the new installation.  That may have been related, also, to my attempt to set up a paging file on one of those other partitions before re-lettering it.  Specifically, the desktop machine had the drive X (BACKROOM) partition just mentioned, as well as an INSTALL partition as drive W, containing my customized Start Menu.

So I started again.  Second time around, restoring again from the Acronis backup of the desktop, I was back to getting the first error reported above:  "Device driver 'PCI \VEN_1002&DEV_4391&SUBSYS_11171043&REV_00' for 'Windows 7' cannot be found."  I wondered if this was because I had allowed the contents of the C:\Windows\inf folder, copied to the external USB drive, to be overwritten by the contents of the System32\drivers folder.  So now I connected the USB drive back to the desktop computer and copied just the inf folder to it.  That is, I did not again copy the drivers folder.  But this was not the solution:  I got the PCI device driver error again.  Puzzling!  After I clicked "Ignore" on that error, it again reported that the recovery operation had succeeded.  I tried to boot the machine into Safe Mode.  It stalled momentarily at the line referring to CLASSPNP.SYS and then restarted itself back to the boot menu.  Second time, I let it try to go into Normal Mode, but that failed too.  Same thing when I selected the Last Known Good Configuration option from the boot menu.  I verified that the INF folder did have a copy of Classpnp.sys.  It hadn't been bad previously.  A search led to the suggestions that this could involve a problem with hardware or a corrupted master boot record on the hard drive.  Someone at Microsoft suggested that Classpnp.sys problems could stem from many sources, including a corrupt registry or a missing or damaged system file or device driver.  It occurred to me that, of course, I had been rewriting the external USB drive with the contents of the inf and drivers folders on the desktop PC, not from the backup of the Eee.  In other words, I had deleted the INF folder, thinking I wouldn't be needing it anymore, and now that I did need it, I had been recreating it the wrong way.  Dumb mistake.  I started over, making sure this time to populate the INF folder on the external drive with drivers and system files from the Acronis backup of the original Eee installation.  I copied both of those folders to the INF folder at the same time, paying no attention as to which would overwrite which.  I tried again with Acronis.  This time, I did something a little different from before.  I had not previously noticed the Options option in Acronis, but now I selected "Validate backup archive before recovery" and "Reboot the computer automatically if needed for the recovery."  But as I saw after five or ten minutes, the validation step was going to take an estimated hour or more, so I clicked Cancel and tried again without that option.  I had already validated the backup when I had made it, so that step did not seem vital.

This time, the recovery process was successful.  Now I had to see about a more cautious way of proceeding.  It seemed that the first task was to create those drives W and X, before something in the registry could try to refer to them and get itself confused.  I wondered if the DISKPART command-line tool would provide a solution.  A search led to a Microsoft webpage telling me basically to go to Start > Run > cmd, here on the desktop machine, and type "diskpart" and then "commands."  The information provided there wasn't very helpful, so I tried a search and concluded that the sequence was, first, to type "diskpart" to get to the DISKPART prompt, and then use LIST and SELECT commands to find the right partition, and then use ASSIGN commands to assign the drive letters.  So the sequence I actually used, after booting up my new Win7 reinstallation (and now it did boot), was to start by ignoring error messages produced by Win7's attempt to identify all the ways in which this Eee PC is so different from the desktop machine where the Acronis drive image came from.  Instead, when the hard drive mostly stops searching, go directly to Start > Run > cmd > DISKPART.  Doing this, while there was still an hourglass prompt, gave me a message, "Windows Explorer is not responding."  I opted to close the program.  The keyboard would not let me type "cmd" -- it was giving me "c0d" instead -- but fortunately there was a drop-down cmd option.  Apparently the installation remembered that I had run cmd on the desktop machine.  So I arrowed down and hit Enter on that.  But this was no solution:  it was not letting me type "diskpart" at the command prompt either.  So now there seemed to be a choice between rebooting or trying to run diskmgmt.msc.

Rebooting seemed like sure death, so I tried Start > Run > diskmgmt.msc.  Here, again, the keyboard was noncompliant; the drop-down option saved me.  It hadn't worked to reletter INSTALL as W first, so this time I began with relettering BACKROOM as X.  That worked.  I was tempted to reboot now, but I thought maybe I should try to clean up as much as I could before taking the risk that the system might never wake up once I let it go to sleep.  The first step, I thought, would be to create a new Administrator profile.  I went into Start > Control Panel but, alas, "Server execution failed."  The keyboard was still noncompliant.  Stuck!  Rebooted into Safe Mode.  Attempts to get into Control Panel from the Start Menu produced "Server execution failed" error messages here too.  I tried to start Control Panel > User Accounts in a cmd box by typing nusrmgr.cpl.  The keyboard was still screwed up, so I tried typing it using ASCII codes:  hold down the Alt key, type the three-letter code, and then let go of the Alt key and repeat for each letter.  So, for instance, from the list of ASCII codes, I saw that the code for the letter U (the first one that was giving me trouble) was 117, so I hit Alt-117.  The Eee PC didn't have a separate numeric keypad (essential for this purpose), so I actually had to hold down Alt-FN and then use the double-purpose keys, which in this case happened to be jj7.  So it was Alt-FN-jj7 to get a "u" on the command line.  This ultimately gave me nusrmgr.cpl, but that wasn't the answer:  I got "nusrmgr.cpl is not recognized as an internal or external command, operable program or batch file."  Another webpage made me think that what I should have been typing was "control.exe nusrmgr.cpl."  I tried that, using the Up arrow and the Home key to recycle the previous command instead of having to retype it.  The command worked, in the sense of giving me another "Server execution failed" error.

Drawing on another source, I tried typing lusrmgr.msc at the prompt and, woo hoo!  that actually opened something.  Under "Local Users and Groups (Local)" I clicked on Users.  Then, from the menu, I selected Action > New User.  I created a new user, Admin2, and then closed out of that.  I right-clicked on Admin2 and went into Properties > Member of (because it only showed "Users") > Add > Advanced.  It defaulted to "Groups" as the object type, so I clicked on "Find Now" and selected Administrators > OK > OK.  Now I seemed to be seeing Administrators as a group that Admin2 was a member of.  In the General tab, I indicated "Password never expires" > Apply.  I restarted the computer in Safe Mode.  It went right in without asking for a password, so I figured I must have previously set Administrator to be the default login.  I went into Start > Shut Down (the little button next to it) > Switch User.  I logged in as Admin2.  No errors!  Control Panel available!  I went into Control Panel > User Accounts > Change your account type.  It wouldn't let me change Admin2 to be an administrator.  I went to Start > Run > controluserpasswords2.  There wasn't actually a Run option, and that command yielded nothing in the search box.  I switched back to Administrator account and tried controluserpasswords2 there.  Ultimately, I wound up back in the Local Users and Groups dialog.  This time, I decided to make Admin2 have the same groups as Administrator, so I used the same procedures to designate Admin2 a member of Administrators, Debugger Users, and HomeUsers, but not of just plain Users.  Then I tried deleting Administrator.  It wouldn't let me delete a built-in account.  I switched into Admin2 and remembered that I could use Start > cmd even if I couldn't use Start > Run.  So in cmd I typed "controluserpasswords2."  But that didn't work either.  David Candy said the command-line equivalent of controluserpasswords2 was "rundll32.exe netplwiz.dll,UsersRunDll." He was right.  There, in the Users tab, I clicked "Users must enter a user name and password to use this computer." That ungreyed the "Properties" option for Admin2, where the Group Membership tab gave me an option to name Admin2 as an Administrator.  Apparently the previous attempt to do that hadn't worked, but now I selected that and went Apply > OK and then unchecked that same "Users must enter a user name and password" option.  Then Apply > OK > logoff.  Now it asked me who I wanted to log in as.  So I wouldn't be automatically out of luck if the Administrator account went south.  I rebooted into Normal Mode and logged in as Admin2.  Still good, but now it was logging that user in automatically.  Turns out I was using the wrong command:  I should have been typing "control userpasswords2" as two words, not one.  OK, so it worked now.  I didn't really want to have to construct a whole new Admin2 account, so I thought I'd try again to fix the Administrator account, now that I was confident that the machine would probably work for me in some sense even if that particular account was fubar.  I logged in as Administrator.  But attempts to do anything still gave me "Server execution failed."

It occurred to me that possibly I could help the situation by going into Task Manager (Ctrl-Alt-Del) and killing programs that might be causing related difficulties.  I basically closed every program that was shown with the Administrator (as distinct from SYSTEM or Admin2) user, except for taskmgr.exe itself.  Then I restarted a session of explorer.exe (using File > New Task right there in Task Manager) and tried again to get into Control Panel.  I still got "Server execution failed."   I could have proceeded on to close system programs in Task Manager, but the situation seemed futile.

In short, I had made some progress and had learned some things, but in the end I had not achieved a superior result over the default installation on the ASUS Eee PC.  It would have been, and was going to be, faster and more reliable to start with the pre-installed Windows 7 on the Eee and build a new user profile -- a copy of the built-in Administrator account, it seemed -- than to attempt to bring one over from the existing desktop computer's Windows 7 installation.  I restored the original Win7 installation to the Eee, arranged my partitions to suit, and began painfully working through the tweaks that I had developed on the desktop computer.  This process, on the Eee, is described in another post.

Friday, March 25, 2011

Windows 7: You Need Permission to Perform This Action

I was trying to move a file from one folder to another.  This was a frequently used folder.  I had done this operation a thousand times before.  Suddenly I got this error message:

Destination Folder Access Denied
You need permission to perform this action
A search led to the suggestion that, in Windows Explorer, I should right-click on the folder and go to Properties > Security tab > Advanced > Owner tab > Edit > select Administrator (since that was who I wanted to own the folder, though that was *already* who owned it) > Apply > OK.  That didn't work.  Some remarks indicated that this could be a digital rights management issue, in the case of a music file, but this was just a PDF.  It was, however, a PDF created by Sumatra PDF, in an attempt to remove security from the PDF so that I could run OCR on it.  It seemed I should have used Foxit instead.  Anyway, I went back into Properties > Security tab > Advanced > Everyone > Change Permissions > Everyone (check both boxes) > Apply > OK.  That didn't do it either.  I moved everything out of the folder, deleted it, put its former contents into a new folder, and was able to work normally.  No explanation.