84 replies to this topic

[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.

[sanbarrow]

esx-tools-016.exe has two functions: install and apply.
So grabbing the files is simply done by running a regular silent installation of dotnetfx.exe like this
dotnetfx.exe /q:a /C:"install.exe /lang 1033 /qb"

As this can be/must be done inside MOA that is pretty easy. The esx-tools.exe does all this and then packs the result into a wim.

I found that dotnet3 is too large to be installed this way so I needed a workaround.
I first load dotnet2 as usual and then add the dotnet3 files with an installrite-kit I created on a 2k3 regular system.

If you are interested in the source-code for the loader I can prepare a package for you.
Some time ago I send the same to Galapo but i don't know if he ever looked at it.

[Lancelot]

If you are interested in the source-code for the loader

will be nice, but dont expect much from me, if galapo is 9 i am only 3 .

a regular silent installation of dotnetfx.exe

if this is a "must" (which we dont prefer much). There is a way for livexp to automize it. But again as i always say, i am in turtle speed, but now only focusing on this.

i will give a shot to esx-tools-016.exe to see what it does.

currently i am trying to make ghost14 rise up with my old .net2 script/plugin .


a warning for dotnetfx35.exe file, it is an incremental file, MS always adds new thing to the package and updates. User may notice the difference from size or version number. Not from name .

[sanbarrow]

Lancelot - I found the approach to grab the files while running MOA the easiest one by far.
This way i do not even have to specify which files to grab.

If you allow users to grab the files while running a regular Windows you will get much stranger results.
One user has this stuff installed - another one has that...
One uses this language and another one that language ...
Oh dear - getting reliable results is much more tricky.

I am just preparing the source code package for you - I'll post the link here:
http://sanbarrow.com...opic.php?t=1359

[Lancelot]

sanbarrow

Yep i %100 understand you, getting strick rules from the begining makes life easy for you. You know, things differ with LiveXP.
Thanks for all help

[sanbarrow]

Don't you have a working msi-script ?
Don't you have scripts that prepare a ramloading NTFS-formatted img ?

If yes - just create a very large ram-loading image and then you can do the same.

You just tell your users - to grab the files for dotnet2 you must use this special build once.

[pscEx]

@Lancelot!

May be you allow me a friend's suggestion:

Inspite Sanbarrow's number of posts in this forum is much less than the number of posts you made:

IMHO in this stuff he is much more experienced, and you should

• Try to understand and follow his ideas, suggestions etc.
  (After switching off your own ideas)
• Try to adapt to LiveXP
  (After switching on your own ideas)

In this order!

Peter

[Lancelot]

Peter,

if you read carellfully , sanbarrow is changing subject from ghost-dotnet to livexp vs moa

I respect all masters experience around including sanbarrow, you, jacklaz, galapo ..........
i made moa build much before than livexp and have a good idea about what it is,
and i guess everyone around know how i fully support lodr in livexp with livexp philosophy (as far as i get).


sanbarrow

please nooo i am focusing on getting wheels turn for now I hope you continue your help when i stuck .

[sanbarrow]

...sanbarrow is changing subject from ghost-dotnet to livexp vs moa

Oops - hope you don't think I am spamming your forum with MOA-advertising like ED_P from 911 always thinks
I just noticed you were talking about loading dotnet2 ...

Anyway - souce code is uploaded to mentioned link.
You will see that you can drop a good part of it as you do not need all the dotnet-VMware apps.
The autoit-script basically does this:

when used in "setup-mode":
create a scratch-directory on writeable disk or ramdrive - in MOA this is always R:\add2win
create junctions from X:\i386 to diiferent sub-directories inside R:\add2win
silently install dotnet2
copy a few files from X:\i386\system32 to R:\add2win\system32
prepare a wim

in "apply mode" it does this:
check presence of R:\add2win - if not available mount add2win.wim to R:\add2win
create junctions from X:\i386 to diiferent sub-directories inside R:\add2win
copy contents of R:\add2win\system32 to X:\i386\system32
apply a registry-patch

Hope that helps to get you started

[Lancelot]

sanbarrow

Thanks a lot, i already got the file and this post will make a good start for me, just need time.

[Lancelot]

I will be away for a while, i guess psc will be very happy with silence of boot-land


Ghost14 trials get a very encouring end with livexp for now

http://img133.images...3/3885/4897.png

maybe not having swprv service cause this !!!
maybe .net i have is not good enough (yet not starterd sanbarrow instructions)
ps: source xpsp2 tested


@joakim
please leave batches extracted for future livexp tests, i cant read Ghost14_LODR.exe but got files by a friend and continue my trials.

Need more time to read...., also have works to do , cu later.

[sanbarrow]

Lancelot - do you have VC-redist runtime ?

[Lancelot]

yep
totally i installed these
vbrun60sp6.exe
vcredist_x86_2005.exe
vcredist_x86_2008.exe
msxml6_x86.msi

but i am not sure what exactly does joakim do with lodr.exe
after installing these i do:
md X:\Lodr\ghost14
junction X:\Lodr\ghost14 C:\lodrfolder\ghost14
register_vss.cmd
ghost14-xp.reg
fixinstall.bat
ghost14.cmd

also added vss service to the build
couldnt find swprv for xpsp2 source (only looked my current scripts, didnt googler because i am tired and very busy tomorrow)
maybe something i overlooked from joakim's routine

i hope info helps, also pmed joakim a script to make sure adding required files+vss service to livexp.

[sanbarrow]

I haven't tried Joakims script either yet - just one more idea ...
did you run
RegWrite('HKLM\SYSTEM\Setup', 'SystemSetupInProgress', 'Reg_Dword', '0x00000000')
before trying ghost ?

[joakim]

Some more info as there seems to trouble with it.

First of all xp is not verified to work. 2k3 and vista is currently verified to work here.

Only junction the dotnet2 package. Do NOT junction anything inside LODR\ghost14.

Only run the loader "ghost14_LODR.exe" once, first time after bootup. Next time you launch the app on same boot, go for the geberated shortcuts, or directly on either vproconsole.exe or vproconsole_.exe inside the LODR\ghost14\Console directory.

The fixinstall.bat can be removed and is never used.
The other .reg and .cmd is what the loader executes the first time to set it all up. Don't bother with them as the loader handles it.

The vss batch was really a collection of commands for all OS's as to have good cover. I will reuplaod this batch for each specific OS.

The swprv service only requires swprv.dll.

Joakim

[joakim]

Here is VSS and swprv for xp/2k3.
The restarts of the eventsystem may be necessary.

[codebox]REM xp/2k3 sc create VSS binpath= "X:\I386\system32\vssvc.exe" depend= RPCSS DisplayName= "Volume Shadow Copy" net stop vss net stop swprv net stop eventsystem regsvr32 /s ole32.dll regsvr32 /s oleaut32.dll regsvr32 /s atl.dll regsvr32 /s vss_ps.dll regsvr32 /s vss_ddu.dll regsvr32 /s vssddups.dll regsvr32 /i /s swprv.dll regsvr32 /i /s eventcls.dll regsvr32 /s es.dll regsvr32 /s stdprov.dll regsvr32 /s vssui.dll regsvr32 /s msxml.dll regsvr32 /s msxml2.dll regsvr32 /s msxml3.dll regsvr32 /i /s swprv.dll Vssvc /Register net start eventsystem net start swprv net start vss net stop vss net stop swprv net stop eventsystem net start eventsystem [/codebox] Look in the OS source and add the files according to the above. Maybe there is 1 or 2 differences in xp and 2k3. Don't remember at the moment.
The vss is necessary for ghost to connect to its local agent and read disk information.

Joakim