Help migrating from Linux to XPe

I am going to attempt to migrate a system of very low-end computers
that currently boot using BOOTP/TFTP/PXE and mount an NFS share for
executables.

I have read quite a bit of documentation from Microsoft, but I want to
get input from active developers.

The server is slated to remain on Linux. Samba already allows me to
support Windows shares. I may need to make the server a PDC, but I'm
not sure yet. The lowest-end client I have is a 200MHz Sis x86
processor with 128 MB RAM. I'm not sure it will be enough to run a
graphical app. Anyone have success with this small a footprint?

The clients are planned to have no storage so I would continue booting
PXE. The users documents, application data, etc. would be on a
network share. In a memory-constrained system, is it better to try
and run applications off a network share or put it in the image? I
know in general you don't want a paging file on a network share, but
is this possible? I guess we could put a CF card in the clients just
for paging.

For a common login environment, do I need to implement a domain
controller or is there a simpler way to maintain a common user
database? I do need the basic features that having separate network
users give you, such as file permissions.

Below is a list of functionality desired in priority order. Lower-end
systems might only have a few of the top features. High-end system
might have them all. Let me know if I am crazy or if this seems
possible.

* A C# .NET 2.0 app that I have source code for.
* Printing
* Email (probably Thunderbird)
* Internet Explorer or maybe Firefox
* Scanner support
* A Windows Explorer type application that would let users manage
their files, but would not let them get in trouble with features that
are in some of Windows Explorer's menus
* Imaging software (something cheap, like GIMP)
* Proprietary applications for which I don't have source code
* Proprietary drivers for which I don't have source code

Looks like you want to do a remote boot of XPe.

1. The XPe tools come with a Remote Boot software for Windows Server. I am
not aware of any other solution to remote boot XPe from Linux Server.
2. Remote boot means remote boot into RAM - your image is going to be way to
big for your low end with only 128MB of RAM. especially using .NET 2.0. OS
footprint sizes could range from 100MB to 512MB. With .NET and your
features, it might be around 300MB. The minimum client needs to be Pentium
III 500 MHz or higher processor with at least 512MB of RAM for normal boot.
More RAM would be recommended for remote boot since you need room for the
image and working memory.
3. If you remote boot into RAM, than a page file is not usefull.
4. You don't need a domain controller if you do not want one. All accounts
can be created locally.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit



<Chris.P.Elliott@gmail.com> wrote in message
news:1170819709.769137.189590@v45g2000cwv.googlegroups.com...
>I am going to attempt to migrate a system of very low-end computers
> that currently boot using BOOTP/TFTP/PXE and mount an NFS share for
> executables.
>
> I have read quite a bit of documentation from Microsoft, but I want to
> get input from active developers.
>
> The server is slated to remain on Linux. Samba already allows me to
> support Windows shares. I may need to make the server a PDC, but I'm
> not sure yet. The lowest-end client I have is a 200MHz Sis x86
> processor with 128 MB RAM. I'm not sure it will be enough to run a
> graphical app. Anyone have success with this small a footprint?
>
> The clients are planned to have no storage so I would continue booting
> PXE. The users documents, application data, etc. would be on a
> network share. In a memory-constrained system, is it better to try
> and run applications off a network share or put it in the image? I
> know in general you don't want a paging file on a network share, but
> is this possible? I guess we could put a CF card in the clients just
> for paging.
>
> For a common login environment, do I need to implement a domain
> controller or is there a simpler way to maintain a common user
> database? I do need the basic features that having separate network
> users give you, such as file permissions.
>
> Below is a list of functionality desired in priority order. Lower-end
> systems might only have a few of the top features. High-end system
> might have them all. Let me know if I am crazy or if this seems
> possible.
>
> * A C# .NET 2.0 app that I have source code for.
> * Printing
> * Email (probably Thunderbird)
> * Internet Explorer or maybe Firefox
> * Scanner support
> * A Windows Explorer type application that would let users manage
> their files, but would not let them get in trouble with features that
> are in some of Windows Explorer's menus
> * Imaging software (something cheap, like GIMP)
> * Proprietary applications for which I don't have source code
> * Proprietary drivers for which I don't have source code
>

Just to throw out an idea...

Chris, have you thought of creating a "thin client image" for remote booting
on the target? E.g., you can use RDP or similar.
Then you could move some [most] of the heavy apps to launch on the server
side.

Depending on what you chose on the client side as protocol (technology) you
may or may not need to got for a MS server. If RDP, you'd obviously need MS
terminal server (e.g., running on 2003 Server).
Or you could use Citrix mainframe.

128M RAM is indeed not enough to load Winlogon image with .Net included. But
it could be enough to run Minlogon image with RDP client in.
There are [were] XPe based thin clients on the market with 128 RAM only.

Regards,
KM

> Looks like you want to do a remote boot of XPe.
>
> 1. The XPe tools come with a Remote Boot software for Windows Server. I am
> not aware of any other solution to remote boot XPe from Linux Server.
> 2. Remote boot means remote boot into RAM - your image is going to be way
> to big for your low end with only 128MB of RAM. especially using .NET 2.0.
> OS footprint sizes could range from 100MB to 512MB. With .NET and your
> features, it might be around 300MB. The minimum client needs to be Pentium
> III 500 MHz or higher processor with at least 512MB of RAM for normal
> boot. More RAM would be recommended for remote boot since you need room
> for the image and working memory.
> 3. If you remote boot into RAM, than a page file is not usefull.
> 4. You don't need a domain controller if you do not want one. All accounts
> can be created locally.
>
> Regards,
>
> Sean Liming
> www.sjjmicro.com / www.seanliming.com
> XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
> Toolkit
>
>
>
> <Chris.P.Elliott@gmail.com> wrote in message
> news:1170819709.769137.189590@v45g2000cwv.googlegroups.com...
>>I am going to attempt to migrate a system of very low-end computers
>> that currently boot using BOOTP/TFTP/PXE and mount an NFS share for
>> executables.
>>
>> I have read quite a bit of documentation from Microsoft, but I want to
>> get input from active developers.
>>
>> The server is slated to remain on Linux. Samba already allows me to
>> support Windows shares. I may need to make the server a PDC, but I'm
>> not sure yet. The lowest-end client I have is a 200MHz Sis x86
>> processor with 128 MB RAM. I'm not sure it will be enough to run a
>> graphical app. Anyone have success with this small a footprint?
>>
>> The clients are planned to have no storage so I would continue booting
>> PXE. The users documents, application data, etc. would be on a
>> network share. In a memory-constrained system, is it better to try
>> and run applications off a network share or put it in the image? I
>> know in general you don't want a paging file on a network share, but
>> is this possible? I guess we could put a CF card in the clients just
>> for paging.
>>
>> For a common login environment, do I need to implement a domain
>> controller or is there a simpler way to maintain a common user
>> database? I do need the basic features that having separate network
>> users give you, such as file permissions.
>>
>> Below is a list of functionality desired in priority order. Lower-end
>> systems might only have a few of the top features. High-end system
>> might have them all. Let me know if I am crazy or if this seems
>> possible.
>>
>> * A C# .NET 2.0 app that I have source code for.
>> * Printing
>> * Email (probably Thunderbird)
>> * Internet Explorer or maybe Firefox
>> * Scanner support
>> * A Windows Explorer type application that would let users manage
>> their files, but would not let them get in trouble with features that
>> are in some of Windows Explorer's menus
>> * Imaging software (something cheap, like GIMP)
>> * Proprietary applications for which I don't have source code
>> * Proprietary drivers for which I don't have source code
>>
>
>