AOSS expert needed to help manually restore an OSS "managed" disk.

I don't see how, under any normal circumstances, OSS would have copied the files to the USB drive. When that feature is used the installed OSS BOOTWIZ folder is used, not one on a drive connected later.

In addition, that feature should only be activated if you installed multiple Windows operating systems into the same partition.

Was OSS also installed on the IDE drive you connected via USB to the bench system?

Clarifying:
The bench system's C drive had AOSS just installed.
When the infected drive from another computer (complete with windows installed) was added via USB, it became D:.

When AOSS saw D, and detected D: could boot windows,
D:\windows was moved to D:\bootwiz\random#\windows
similarly the other two folders and boot.ini

Later I unmounted D: and replaced it as C: in it's own computer (without AOSS). No boot. Moved the drive to a laptop without AOSS, (again USB), where it was also D:, found the stuff under D:\bootwiz, and drug it back to the root of D:. It looked normal, but only because I didn't look INSIDE the 3 folders, so I didn't see that access was denied and the path was inaccessible.

tried again to boot original system from the drive. no joy.
tried MBRfix, no joy
remounted on laptop, found inaccessible errors.

No files were moved across disk or partition boundaries.

I've never heard of OSS doing that. It's certainly odd.

What build of OSS are you using?

I assume that OSS screwed up all the permissions for the files/folders.

You could try copying the files/folders to a FAT32 partition, deleting them from the original partition and then copying them back.

A Live Linux CD (Ubuntu, Knoppix, for example) may allow access.

You might also consider creating an image backup of the partition before making any further changes.

Running a chkdsk may also fix some problems (it may also cause some). You may want to run it with no fixing options and see what it reports and proceed from there.

---

In my experience with OSS, I've found it best not to connect any drives (especially bootable drives) to a computer with OSS activated. OSS tends to "take them over" and that can cause problems. Best to deactivate OSS first or use a computer without OSS.

Thanks Mudcrab for trying to help.

> I've never heard of OSS doing that. It's certainly odd.
At first I thought it was malware-induced, then I found a post elsewhere referencing the behavior from AOSS.  That issue was solved by mounting on another system with AOSS and "reversing" the behavior (no details).  So my first goal is undo my move and get it back the way AOSS expects it. Then try to figure out what is required to get AOSS to reverse it's action.

> What build of OSS are you using?
Came with DDSuite 10

> I assume that OSS screwed up all the permissions for the files/folders.
At least, maybe more, I don't know.

> You could try copying the files/folders to a FAT32 partition,
> deleting them from the original partition and then copying
>  them back.
I'd be willing, if someone who's familiar with the behavior said that would work.

> A Live Linux CD (Ubuntu, Knoppix, for example) may allow access. 
This isn't my disk, I want to avoid "try"ing, I need Acronis support to provide an answer.

> In my experience with OSS, I've found it best not to connect any drives
> (especially bootable drives) to a computer with OSS activated.
> OSS tends to "take them over" and that can cause problems. Best to
> deactivate OSS first or use a computer without OSS.
I didn't expect the take-over behavior.  Some dogs bite first, and bark later.

Still in need of an answer from someone who know what AOSS did, and how.
- How do I proceed to undo my manual move of the files,
- to get AOSS back to his expected state
- how do I get AOSS to reverse it's mods and restore the 3 folders and
- make the drive bootable again.

Do you have a link to the other post where this problem is referenced? It may help me to read it.

The build of OSS is the same as DD. Check in the Help >> About menu of either DD or OSS.

FAT32 partitions don't preserve permissions. This is why I suggested copying them to a FAT32 partition, deleting the originals and then copying them back.

The fact that you don't want to cause further corruption is why I suggested creating a backup image of the partition/drive. At least you could then return to the current state and try something else, if necessary.

Acronis Support rarely (and by rarely, I mean almost never) posts about OSS problems. I'm pretty much considered the "OSS Expert" on the forum.

When OSS takes over a drive, it usually modifies the MBR so that it will boot to the OSS menu (usually on a different drive). Sometimes this renders the drive as unbootable or just makes it show a "MBR Error" and booting continues.

Since you have already manually "moved" the files that OSS moved, there may not be a way to have OSS restore them (it may not have been possible before). I assume when you "drug it back to the root of D:" that you actually moved the files and the originals are no longer in the BOOTWIZ folder. Is that correct?

Do you have a link to the other post where this problem is referenced? It may help me to read it.
See PDF attached

FAT32 partitions don't preserve permissions. This is why I suggested copying them to a FAT32 partition, deleting the originals and then copying them back.
I'm concerned because I already know they've done something totally abnormal.  I just don't know what.

The fact that you don't want to cause further corruption is why I suggested creating a backup image of the partition/drive. At least you could then return to the current state and try something else, if necessary.
No spare disk to image onto.

Acronis Support rarely (and by rarely, I mean almost never) posts about OSS problems. I'm pretty much considered the "OSS Expert" on the forum.

When OSS takes over a drive, it usually modifies the MBR so that it will boot to the OSS menu (usually on a different drive). Sometimes this renders the drive as unbootable or just makes it show a "MBR Error" and booting continues.

Since you have already manually "moved" the files that OSS moved, there may not be a way to have OSS restore them (it may not have been possible before). I assume when you "drug it back to the root of D:" that you actually moved the files and the originals are no longer in the BOOTWIZ folder. Is that correct?
The results of my manual move should have been predictable.  The fact that it's not predictable leaves me thinking they did some high-tech wizardry.  I have no time to make this an experiment.
If you've never seen the behavior, do you know someone inside who can at least confirm which of your suggestions will work? 

This question has been live around 48 hours.

Let's summarize:
I'm stumped, I re-format less than 5% of all cases,
tomorrow sometime I'll have no alternative because
Mudcrab's is stumped, he's the expert in lieu of a vendor response.

In my original question, I stated:
"I found a reference in the sticky on this forum, to a manual uninstall. Perhaps it would help, but It denied me access:
Login successful. Access Denied You are not authorized to access this page. "

Not only did nobody offer me a working link, but nobody from the company has offered any information. Kudo's to Mudcrab for doing his best, but this is a deeper question, requiring only a small amount of insider information, maybe as little as the manual uninstall link.

I've also sought an answer from the 50,000 experts on www.experts-exchange.com, they're stumped, and resorting to experimenting.

Highlights:
- "Acronis Support rarely (and by rarely, I mean almost never) posts about OSS problems. I'm pretty much considered the "OSS Expert" on the forum."
- The "OSS expert" says: I've never heard of OSS doing that. It's certainly odd.
- I'm not the only one to experience it, there's a track record.
- There's even evidence it's been documented and fixed in the forum, for someone else.
- The vendor isn't responding in their own support forum.

I was led to expect higher quality from Acronis, I didn't expect the quality to end at the cash register.

So... tomorrow when I close the question on
Experts-Exchange, is there any further information I can include for the sake of future victims of circumstance? When 50,000 consultants like myself search the EE database for product recommendations what should they learn from my post?

I can understand your frustration. I believe the problem is very rare with OSS. In my opinion, the fact that the thread you found was from 2005 is proof of that. The solution in that case, as I read it, was to install OSS onto the computer, configure the correct settings and then OSS could be removed or used as desired. As far as I can tell, this was DD/OSS 9, not version 10.

I don't think that the manual uninstall instructions for OSS would help in this case since OSS was not installed on the other computer. Installing it may help (as in the thread you found), but it would also require the files to be as OSS expects them. Can you put them back like they were?

Even if that were done, it's very unlikely that OSS would assign the same ID to the OS entry on a new install on a different computer as it did when you connected the drive to the bench computer.

If you have the time to wait, I may be able to find the time to run a few tests tomorrow and see what I can find out.

I would need the following information from you:

• What OS and SP level was installed on the bench computer?
• What OS and SP level was installed on the drive from the other computer?
• What build of OSS are you using?
• Exactly what error message(s) are you getting when you try to boot the drive in the original computer?

Are you sure that the Windows partition is setup correctly on the drive? It would normally be Active. Is the boot.ini file configured properly? OSS may have left either of these in a non-standard state. It's also not uncommon to be unable to access system files from one computer on a different computer. The main thing is if the original OS can access the files.

When OSS adds a Windows OS, it detects the version of Windows and automatically sets up the system folders. These would be C:\Windows, C:\Program Files, and C:\Documents and Settings for XP. For each of these, restoring the folders back to the original locations can be enabled or disabled. The default is disabled (they remain in their original locations). I have no idea why OSS would automatically enable this option for the Windows on the attached drive. (From an old post by Acronis Support on Wilders, it looks like OSS 9 did copy the files by default, but it's unclear whether it was the system folders or only the booting files -- which are tracked for changes.)

If you still have OSS on the bench computer and haven't changed anything, it may be possible to use it to disable the option for the OS on the attached drive. However, the same problem remains: you moved the files. In any case, this method would probably be more likely to succeed than on the original computer as long as OSS still sees it as it did before (same OS ID, etc.).

---

What should be learned? Make a backup image of a drive before making any changes. This includes partitioning changes, virus cleanups, etc. You never know when a problem may occur.

Huzzah for the valiant MudCrab... thanks again.

What OS and SP level was installed on the bench computer?
XPsp3, OSS 10.0 build (2,160)

What OS and SP level was installed on the drive from the other computer?
XPsp3,

What build of OSS are you using?
Laptop, XPsp3

Exactly what error message(s) are you getting when you try to boot the drive in the original computer?
win logo
...
Autocheck program not found - skipping autocheck
...
bsod
stop c000021e {fatal system error}
The session manager initialized system process terminated unexpectedly with a status of 0xc0000022 (0x00000000, 0x0000000000)

As I stared at the ceiling last night, the 2005 of the old post also date crossed my mind, along with the fact that the Roxio GoBack v3.0 also pre-dated the user's inheritance of the system. IF the prior owner had GoBack, might he have also had an old version of OSS? Might my bench v10 have triggered his old v9? So I used ERD to boot the original system and examine the drive for c:\acronis, nothing.

I'm out till around 11am EST.

Interesting idea. I assume you also looked in C:\Program Files\Acronis? Are there any BOOTWIZ folders on any other partitions? Check the creation date for the folder and see if it's prior to when you connected it to the bench system. Also check the sub-folder dates in the BOOTWIZ folder on the attached drive (if the folders still exist). For example, the \BOOTWIZ\#######... folder.

On your bench computer, did you check in the main BOOTWIZ folder to see if it copied any of the files into that folder. The ####### folder is the hex ID value assigned to the OS (it's decimal in the BOOTWIZ.OSS file).

Interesting idea. I assume you also looked in C:\Program Files\Acronis? Yes, no such directory.
Are there any BOOTWIZ folders on any other partitions? No other partitions recognized by windows via USB cable.

Check the creation date for the folder and see if it's prior to when you connected it to the bench system. Also check the sub-folder dates in the BOOTWIZ folder on the attached drive (if the folders still exist). For example, the \BOOTWIZ\#######... folder.
All dates 1/15/2010

On your bench computer, did you check in the main BOOTWIZ folder to see if it copied any of the files into that folder.
The ####### folder is the hex ID value assigned to the OS (it's decimal in the BOOTWIZ.OSS file).
The bootwiz folder on the C: drive of the bench computer shows no signs of the problem disk ever having been attached.
It has a different ####### number, no windows... folders.

BTW, Disk Director had been refusing to copy the partition all along.  I've had the files
backed up on the spare drive where I would otherwise put the image,
earlier today I shuffled things around, DD still wouldn't copy it..

So... since today got hijacked by other priorities, tomorrow afternoon I'll be trying the following steps.
(please feel free to make further suggestions).

1) restore the MBR from backup (MBRfix was last thing I did before seeking help, first to undo)
2) force ownership of the inaccessible files, hoping no other tech wizardry was performed
3) move the files back where I found them
4) see if I can figure out how to ask OSS on the bench system to undo his deeds
    (is there something other than uninstall that will accomplish the undo?)
5) chkdsk
6) try again to dupe the partition
7) replace the disk in the original system
8) boot
9) remove GoBack
10) reboot
11) On bench system uninstall OSS

Thanks again MudCrab, for all your time and attention.

If at all possible, I would still recommend creating a backup image of the drive before continuing.

If you connect the drive back to the bench computer with OSS, it should "reconnect" to the existing entry/ID, if it still exists. If it does, check the settings for folder protection and see if it's enabled for each folder. If it is, you may want to disable it for each folder and see if it copies them back. I'm not sure if a boot attempt would need to be made before or after the change.

I didn't have time today to run any tests and I'm not sure about tomorrow. I may try to do a quick test later tonight. I'll see how it goes.

Is DD giving an error message when you try to copy the partition?

Okay. I ran a few tests.

Enabling folder protection moves the folders when you click OK on the Properties window (no reboot or booting into the OS is required).

Disabling folder protection moves the folders back when you click OK on the Properties window (no reboot or booting into the OS is required).

This seems like the simplest method to use if OSS will pick it back up as the same OS. Just disable folder protection for the three folders. Note that the contents of these folders MUST be back in the BOOTWIZ\#### sub-folders for this to stand a chance of working.

----

I also tested leaving folder protection enabled and then moving the files from the BOOTWIZ sub-folders back to their original locations. Note: I didn't move the "base" folders (C:\Windows, etc.). I just moved the contents of those folders. For example: I browsed to the Windows sub-folder in the BOOTWIZ\#### folder, selected all the files/folders, cut, browsed to the \Windows folder and pasted. I would also note that in one of the folders (Program Files), it took a second attempt to get all the files moved.

XP booted up fine. However, it wanted to reinstall some drivers that were previously installed. Trying to update seemed to error with some permission issues. Access Denied in some of the Program Files folders. Basically, I had to reset permissions back to what they were (or perhaps higher -- I didn't check). I did this while booted into Windows. I don't know if you can set the permissions for the booted system from "outside" the booted system.

---

I hope this helps.

MudCrab,
VERY VERY helpful.
Now I will approach the task with some hope since I'm not the only one to ever see the files move AND I know it's possible to make it work.
Dial-a-fix (you can find it through MS's KB) will probably fix up the permissions.

Is DD giving an error message when you try to copy the partition?

No, just never completes the selection of the target unallocated space.
I suspect it's some relic of the GoBack configuration.  When GoBack was turned on,
nothing even recognized it as a legitimate partition.

Here's what I went through to solve the problem. The numbered steps relate to the plan I listed above,
which was not far off.

1) restore the MBR from backup (MBRfix was last thing I did before seeking help, first to undo)
2) force ownership of the inaccessible files, hoping no other tech wizardry was performed
did this on laptop, disk mounted on USB. Turned out eventually that it didn't completely set the
permissions, but enough to get the job done at this stage
3) move the files back where I found them
The move took much longer than any span of time the bench machine ever spent,
leading me to believe AOSS transplanted directory entries manually bypassing windows routines.
(there's an example of the kind of wizardry I expected).
4) OSS saw the partition as Windows, but said the boot partition was missing
and offered no options.
By groping around the menus I found the setting for "protect the files"
but changing its setting did nothing about moving the files.
so I moved them manually (after taking ownership on the bench machine)
Ran the OSSelectorSetup in c:\program files\acronis and choose to uninstall it. reboot
The bootwiz folder is gone off subject disk drive
In theory, we should be back where we started before OSS mangled it, though the
"boot partition missing" from OSS isn't encouraging

In reality, it needed a bit more brute force.

At first it was just white cursor on black screen. I discovered some files in the windows folder were still inaccessible due to security settings. I added everyone-full access.

Then it was logging in and immediately logging out, so I just opened security across the whole drive, then I could log in.

It was probably a result of malware, though a failed Norton install, and an ancient copy of Roxio GoBack 3 all happened too.

I used an old copy of ERD Commander 2005 to reset all the permissions in one swell foop,
(it cried about non-existent tokens, probably from the domain the system had been removed from years ago ).

I've not yet repaired the file permissions, but I expect Microsoft's KB 313222 will do well enough since it's now a solo home system.

Thanks again BlueCrab for going far above and beyond what any non-employee should ever have to do. I've posted the solution here for some poor soul that stumbles into the same snare. My advice, uninstall OSS as soon as you fix the problem, you don't want your entire system relying on the delicacy of an unsupported bit of wizardry.

Oops, Thanks again MudCrab!

Hello All,

After spending the last 4 days trying to get my win7_64bit HP Laptop up and running from the installation of the AcronisDD11 OS Selector, I need to post the following information. Not been able to install the Beta of ATI11 due to fragments of ATI2010 including Plus Pack and ADD11 including the OS Selector (Not installed until last Saturday), I decided t install the selector and see if it would uninstall and free up some of the other parts of Acronis software that may be hindering me from installing ATI2011. Bad idea, as the OS Selector corrupted my Win7_64bit Boot Manager, which caused the computer NOT TO BOOT PERIOD. I did have Windows Recovery disk, which I ran several times but would not boot the computer. I would get the message: "Starting Acronis: Press ESC for Menu: Press F6 to Skip Menu; Unable to Execute Command". I had a created an Acronis Recovery CD with one of my backups that didnt' work either. After checking online through the Acronis forums and Microsoft sites for a fix, I downloaded the Acronis Bootable Media which, again would not boot my computer. Finally, using the Windows Recovery Media, I was able to go into the command prompt and reset the Boot values, which didn't help. I did get the ADD11 Bootable media to open ADD11 and I was able to see my Harddrive and all files, but couldn't open the files to view the BOOTWIZ values or anything else.. I even tried to get the Windows CD to run; didn't happen. Through all of this for the past 4 days, I finally received a message within the system that I did NOT HAVE A BOOT MANAGER INSTALLED. Finally, here is the reason the computer would not boot. Knowing what I had tried in the past 4 days, I decided to reset the system, which I did and then ran the WINDOWS REPAIR CD which fixed the Boot manager and I am up and running again. The purpose of this post is to advise Acronis that we need some changes in the way their software integrates into operating systems and WE NEED A FIX TO BE ABLE TO COMPLETELY UNINSTALL THEIR PRODUCTS WITHOUT LEAVING FOOTPRINTS. At this point in the ATI11 Beta, I will have to reformat and reinstall my system to UNINSTALL the Acronis product fragments I have so I can Install and use either ATI2010 and/ or ATI2011 when the testing is over. ADD11 is an excellent product as is ATI2010, but the OS Selector NEEDS WORK.

Regards,

Hal