WinXP Pro - or at least a configuration / setup

For building a WinXP LivePC, please see the "xpfromcd" tool we just released. You can build a new WinXP LivePC in one click and about 30 minutes of waiting.

Regarding Linux, I've built a bunch of Linux LivePCs and I agree, it would be very nice to have more tools to e.g. automatically install moka5/VMware tools and automatically configure the LivePC. We are working on improving the tools in that area.

The nice thing about Linux is that there are no limitations in posting and sharing LivePCs. So if one person sets it up, you can just start with that and you don't have to do all of the work. It's even more efficient because the image is stored compressed, and when you publish users only have to download the differences between your version and the base version. We have a handful of Linux base images up that are configured "the right way" with moka5/VMware tools installed, /home mounted on a persistent disk, shared folder with the host, etc. If you build a LivePC with another distribution, please consider posting it to the BetaGarage so others can take advantage of it. Thanks!

-John

Hi John.

Where does one find this xpfromcd? Does it come as part of the regular LivePC download?

-Joos.
aka Jeremy Lueck
JoosSearch

You can get it from here.

i have some error with xpfromcd


This script requires a temporary folder with at least 1200MB of free space.
Enter temporary folder path (eg, C:\Temp ): C:\temp
This script requires a temporary folder with at least 1200MB of free space.
Enter temporary folder path (eg, C:\Temp ):

i have over 66GB free :/

We are aware of this issue on the xpfromcd with the non-US-English versions of XP.

Kevin

I have a related question: I would like to create a set of LivePCs to simplify system administration. For example, I would like to be able to install patches, new software, etc. and simply nuke (er, replace) the LivePCs with the upgraded systems.

The catch is that each LivePC needs to be configured once it is loaded. First, the software keys such as Windows Activation need to be entered. Second, the virtual machines need unique system names (e.g. PC001, PC002 instead of all named "WinXP").

How can you best setup one master LivePC and then configure it for the individual clients? I have looked at xpfromcd but this is only a base installation; it does not include additional software.

Please keep this on topic -- I am not looking to debate open source vs. proprietary software.

Many thanks.

Hi Gglockner,

>> First, the software keys such as Windows Activation need to be entered.

Thanks this is a great question. In fact I've been looking at this problem myself too...

The LivePC Engine in its current shape does not support this but I can think of a somewhat convoluted workaround. This can be complicated and is not a supported way to do things and therefore may break. I haven't had the chance to try this yet so please try it only if you like to try out an adventure :-)

If you look at the 'activation' directory, files stay there after you have turned on the 'Let me make changes' option.

Therefore, what you would do for each client will be:

1. Publish your base LivePC
2. Subscribe to LivePC
3. Turn on "Let me keep changes" option
4. Perform all the client-specific steps - eg, change product key, put in system-level settings etc
5. Package - only package the differences - because you are only packaging the difference, it is going to be small
6. Publish your client-specific LivePC as a new LivePC on our website -- eg, call it PC001
7. Repeat above steps for each client -- after all, if each client has unique key you have to do this manually anyway...

What you would do for updates:

1. Update one image, from your base image above, publish it
2. For client PC001, make a copy of the small 'client-specific' package, call it PC001C
3. Here is the tricky part: hand-edit the vm.xml file in the package for PC001C (do NOT change PC001, change the copy instead) such that it incorporates the system.cdsk from the updated image. You should be able to do it simply by doing a copy and paste of one xml tag to the right position in the xml file. If you need help doing this please let me know.
4. publish PC001C with the vm.xml modification above, as an update
5. Client will automatically pick up the updated LivePC -- along with the product keys etc
6. start the LivePC - you will notice that the retail XP license key and various other configurations should now correct and specific to that client
8. Once you understand how this edit works you can imagine easily writing a script to automatically create PC002C, PC003C, etc for each client. This way you update the OS once, clients keep their configs, and clients get your updates easily
9. Limitations: the updates must be applied to the previous OS -- ie, you cannot reinstall OSes. Also, all files related to the settings must be 'locked down' in the filesystem so that their disk block locations do not change. In the case of product keys this probably means registry files and maybe a few more...
10. Possible Security hole: a sophisticated user can look at the vm.xml file and find your 'base image', and therefore gain access to the 'base image', including access to its product key. You may need to consider that...

Again, as I mentioned before I haven't had the chance to test this out yet so there's a chance it won't work -- as far as I know it works in theory ;-)

Depending on user requests we are also considering the possibility of putting a feature in to make this easier. However, I cannot tell you whether this feature will go in at all because so far you are the first person to ask for something like this :-)

>> Second, the virtual machines need unique system names (e.g. PC001, PC002 instead of all named "WinXP").

Could you please elaborate on why you will need to do this? Is it because you need to run multiple LivePCs on one machine? Anyway, if you use the approach above you will somehow get this too because each LivePC PC001, PC002, etc is now its own 'subscription'.

Please let me know if you have further questions! Thank you for trying out the LivePC Engine!

Thanks,
-Gerald
moka5 Team

Gerald:

Thanks very much for the suggestion. The one issue that seems to be a show-stopper is the registry. It is not realistic to expect the LivePC clients not to update the registry. Just changing some simple preferences in Windows would trigger a change to the registry.

Anyway, the motivation for this would be to roll-out desktop systems for multiple users. If you have three people working simultaneously on a LAN, you could get some strange network errors if you have multiple virtual machines with the same computer name.

I think I'll just stick to one initial image. When configuring a new virtual machine, I would simply use this as a starting point, sort-of like a cloned disk image. Then the VM would get its own machine name, activation key, etc. If the machine needed to be rebuilt (due to virus, spyware, rootkit, etc.) then I could revert back to the original image.

I'd probably keep the recommendation of having two partitions -- one for binaries, the other for data. At least I could always nuke the binary partition while keeping the data and documents. Though this is no different from a physical disk.

Thanks, Greg.

Hi Greg,

Better support for doing exactly that (customizing a base image for a particular machine or user, for example to set machine name, user name, activation key, join a domain, etc.) is something we are actively working on. The idea is that each time a client downloads a new version of a LivePC, it would run a customization step on it. If you are interested in helping to test out this feature, please drop us an email at [email protected] with some more information about what sort of things you would like to see done in the customization step.

If the changes can be localized to a separate disk, you can achieve what you want to do with the current version of the LivePC Engine by simply making that disk persistent. For example, we redirect the user profile to a separate persistent disk so each user can have their own profile, while we independently update the system disk. But if you need to make changes to a file on the system disk such as the system registry, you will have to use the soon-to-be-beta feature I described above.

-John