[LODR-U] Ghost 14 & Backup Exec System Recovery 8.5.3, Finally working in a pure PE (2003/Vista/2008/Win7 - sources) External links Options

[joakim]

22.09.09; besr853_ghost14_v4.zip
17.09.09; besr853_ghost14_v3.zip

24.05.09; dotnet2.rar

23.05.09; besr853_LODR_v2.0.0.1.rar
23.05.09; ghost14_LODR_v2.0.0.1.rar
23.05.09; dotnet2_livexp_2k3.rar(28Mb)

06.05.09 Ghost14_LODR
08.05.09 ghost14_LODR_v1002


For those struggling with this application to work in Preinstallation Environments;

It is now running fine, at least in MOA with 2k3 sources;



Because of its size it may only be feasable to add as a lodr package....


Joakim

[risolutore]

Very good news. I read also in Ghost14 topic that it works only with 2k3 sources :-(
It would be possible a day in the future to have a backup solution from SymanXX working in Pe?

[joakim]

Very good news. I read also in Ghost14 topic that it works only with 2k3 sources :-(

It does not mean ghost14 will not run in pe mode on xp sources. Remember it was meant for xp. It only means that something in my current ramloading xpe build is preventing it from starting. It is very likely that these two backup solutions will run in PE-mode with any sources between xpsp2 - 2k8 regardless of which project made the bootcd, as long as the requirements and dependancies are there.

It would be possible a day in the future to have a backup solution from SymanXX working in Pe?

Well what you see on the image is exactly a backup solution from SymanXX working in Pe. The reason why they have not supplied winpe recovery cd with backup-mode support, is likely because of license control difficulties. On that particular image it is running in moa with 2k3 sources. I can't see any reason why it should not also work with xp sources, or vista or 2k8 for that sake. If someone could just point me towards what could be the reason why I can not create junction points in winpe with either vista or 2k8 sources, then I could test this with such sources as well.


Joakim

[joakim]

First lodr package of ghost14 is finished; ghost14_LODR

It follows the same principle as the vmware workstation package. Collect the file and put them on an external disk with root directory named LODR. Put the ghost14 directory in LODR directory as well as the executable Ghost14_LODR.exe.

Note.
You will need dotnet2.
You will need to register vss with the attached batch.
You will need to start the msiserver service prior to first time execution after boot.

It is working in backup mode on 2k3 and vista. It may work on xp as well, but my build is kind of broken. Report back if anyone got an xp build it works on. Not sure about 2k8, have done some tests but no success yet.

For the curious ones, the loader will write a batch named ghost14.cmd inside the ghost14 directory. That's where all the magic is to get this app and its services registered correctly.

Joakim

[Lancelot]

I cant support/test much for now but I am glad you are the soul of LODR around

just a question, what you suggest for livexp using dotnet2 ? is there a lodr i missed
ps: maybe you mean "lodr for moa", if so can you point me the right direction to use it with livexp (if needed what should i change on pe settings or batch !)

what could be the reason why I can not create junction points in winpe with either vista or 2k8 sources

not being a vistape user, curiosity, is answer fbwf ? and solution ?

[joakim]

About dotnet2:

To be able to junction dotnet2 into X:\ you will have to make a ramloading image with xp/2k3 sources that is ntfs formatted. I have used Ulli/sanbarrow's way of doing this and can upload the necessary registry patch with batchscript if wanted. Maybe frodo wants to post something about his way of a slimmed down dotnet2 version for xp..

If using fbwf, there is no way of making junction points and you have to have dotnet2 present on your ramloading image already. Well you can also make an installrite package and install that onto a cdfs if using fbwf.

I am not entirely sure if that will work, if you at the same time not have any locally ntfs formatted disks mounted. The reason is limitations in vss.

I don't know if any xp-based winbuilder projects have a working dotnet2 script..

If, on the other hand, you are using vistape with either vista or 2k8 sources, you also can NOT make junction points (limitation in the current wim format). That means you will have to include a dotnet2 script in your vistape build.

I do have a theory that maybe it's possible to use a ntfs formatted disk image with compression (like with xp/2k3) and use it with winpe2.x and vista/2k8 sources. That means a replacement of boot.wim with something.img and update the bcd store accordingly. Have not tested this and not sure if it's possible, but if it is then we can make junction points on winpe2.x.

Joakim

[Lancelot]

Totally understand

vistape using blabla.img instead of blabla.wim sounds like a good idea.........Anyway, for now .img required is enough for a start .

We have an old donet2 which worked for livexp, i will give it a try.
But yep better to have a fresh lodr pack registry patch with batchscript if available will be nice ! .
(waiting login registration now, moa site always seems a bit complex to me, need time to find framework lodr pack and activation to download).


Cu

[joakim]

Some more information with instructions about LODR packages supplied by me:

LODR was initially proposed by Mr.VMware4PE at www.sanbarrow.com and stands for Load On Demand Ready (package).

My interpretation and implementation of this is reflecting my opinion that it is better create packages that will be "universally" attacheable to running windows bootcd's. That means having support for xp, 2k3, vista, 2k8 and windows7. Ideally the package detects the environment and patches its own registry patches according to what the environment requires. That is mainly 2 sides, xp/2k3 and vista/2k8, that are somewhat similar. Some apps still need different setups in all OS's and some apps don't even run on all OS's.

Ghost 14 for instance is still under testing on 2k8 based vistape. Looking promising although official support is not there by Symantec on that platform.

I also believe that making such LODR packages only makes sense on larger more complex apps that require the installation of several services and kernel drives and has total size of 50 Mb or so. Putting such larger apps onto the build in the form of plugins (.inf or .script) will increase the size substantially as well as reducing boottime. Therefore have them on external storage and load them on demand.

The idea of the root directory named LODR was just something I needed to simplify the registry and batch patching on my own special implementation. That is to have a given directory structure and a registry patch with known paths inside, and thereby executing a search/replace function to account for changing driveletters that the external storage medium is mounted as. The giveup of the given directory structure would require a more robust search/replace function that would more closely resemble a real install.

The loader is meant to be executed only once. Subsequent restarts of the app should use the shortcuts generated. There will be a new entry in the start menu called LODR with subentries named after the package. The shortcuts obviously will only work if you have booted into a shell, ie not a standard winpe bootcd.

Whatever is written during loading process goes into %temp% as well as to LODR\ghost14\. All else goes into X:\ and is gone after a reboot. The loader will still have to be loaded first each time on a new bootup.

Next step now is finishing Backup Exec System Recovery 8.5.3 which is very similar, yet slightly different.

Joakim

[sanbarrow]

@ Lancelot
The MOA LODR-pack I use to load dotnet2 is called esx-tools-016.exe in the latest version.
It does also load Java runtime and several apps related to VMware.

Are you interested in a dotnet-only package ?
As Joakim already mentions that approach needs X formatted as NTFS and you must be able to set junctions on X:.
It is not necessary to be able to mount wims - I use wims only for CD-only builds.

Ulli

[Lancelot]

Thanks for posting sanbarrow

Are you interested in a dotnet-only package ?

yes

As Joakim already mentions that approach needs X formatted as NTFS and you must be able to set junctions on X:.

no problem for LiveXP . Getting .net lodr into LiveXP is one my my goals (and obtionally and prefered with wim file).

just got esx-tools-016.exe but....

For now the procedure i am looking for is:
1) extracting a dotnetfx.exe (or dotnetfx35.exe ---> which includes net2 net3 etc.... .net2 is in \dotNetFX20\...msp ) (or maybe NetFx20SP1_x86.exe)
2) the batch you made + tools if needed which makes the wheels turn .

if 1 is not available but files can be obtained from a xp32 pc by gathering files, please indicate which .net2 to install to a xp32 so i can gather correct files guessing with a collect batch .


Edit:
i am not as fast as galapo (or others around) . I remember we wrote this issue in last times of lodr topic, but never found time since now.