[coderer@gmail.com]

A colleague of mine wants to be able to manage user accounts on an
EWF-protected, read-only XPe system, probably by storing the account
info on a secondary (writable) device like a hard drive. I told him
this defeats a lot of the purpose of EWF, but he's curious if it can be
done anyway. Does anybody have any ideas? I figured it's easy enough
to point somewhere else for the Documents and Settings directory, but
what about registry/.SAM file/etc.? Any experience, or is this just a
non-starter?

[KM]

You can move user profiles to another directory (disk).
You will have to change "ProfilesDirectory" and "ProfileImagePath" values under key and subkeys of [HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList].

--
KM,
BSquare Corp.
www.bsquare.com


>A colleague of mine wants to be able to manage user accounts on an
> EWF-protected, read-only XPe system, probably by storing the account
> info on a secondary (writable) device like a hard drive. I told him
> this defeats a lot of the purpose of EWF, but he's curious if it can be
> done anyway. Does anybody have any ideas? I figured it's easy enough
> to point somewhere else for the Documents and Settings directory, but
> what about registry/.SAM file/etc.? Any experience, or is this just a
> non-starter?
>

[Matt Kellner \(MS\)]

However, the system's awareness of those extra accounts when they're created
may still be limited if the appropriate registry changes can't be written
because of EWF. Do you know if just creating the user account folders is
enough?

--
Matt Kellner (mattkell@online.microsoft.com)
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================

"KM" <konstmor@nospam_yahoo.com> wrote in message
news:O30veQpcFHA.584@TK2MSFTNGP15.phx.gbl...
> You can move user profiles to another directory (disk).
> You will have to change "ProfilesDirectory" and "ProfileImagePath" values
> under key and subkeys of [HKLM\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\ProfileList].
>
> --
> KM,
> BSquare Corp.
> www.bsquare.com
>
>
>>A colleague of mine wants to be able to manage user accounts on an
>> EWF-protected, read-only XPe system, probably by storing the account
>> info on a secondary (writable) device like a hard drive. I told him
>> this defeats a lot of the purpose of EWF, but he's curious if it can be
>> done anyway. Does anybody have any ideas? I figured it's easy enough
>> to point somewhere else for the Documents and Settings directory, but
>> what about registry/.SAM file/etc.? Any experience, or is this just a
>> non-starter?
>>
>
>

[KM]

Matt,

> However, the system's awareness of those extra accounts when they're created may still be limited if the appropriate registry
> changes can't be written because of EWF. Do you know if just creating the user account folders is enough?


It is not. You will also have to make sure that user account profile registry branch is properly created (or moved) to the new
folder (ntuser.dat).

I assumed that changing profile paths is committed if EWF used. (this should be done once, or set up in pre-FBA image by loading the
software hive offline)

SAM database shouldn't be of much concern if user account passwords do not change often (if they do, EWF overlay should be
committed).

As an experiment, this all can be done on working runtime (no need to re-build, re-FBA the image). Better to set up registry entires
and move folders offline, though.

--
KM,
BSquare Corp.
www.bsquare.com


> --
> Matt Kellner (mattkell@online.microsoft.com)
> STE, Windows Embedded Group
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> ===============================
>
> "KM" <konstmor@nospam_yahoo.com> wrote in message news:O30veQpcFHA.584@TK2MSFTNGP15.phx.gbl...
>> You can move user profiles to another directory (disk).
>> You will have to change "ProfilesDirectory" and "ProfileImagePath" values under key and subkeys of
>> [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList].
>>
>> --
>> KM,
>> BSquare Corp.
>> www.bsquare.com
>>
>>
>>>A colleague of mine wants to be able to manage user accounts on an
>>> EWF-protected, read-only XPe system, probably by storing the account
>>> info on a secondary (writable) device like a hard drive. I told him
>>> this defeats a lot of the purpose of EWF, but he's curious if it can be
>>> done anyway. Does anybody have any ideas? I figured it's easy enough
>>> to point somewhere else for the Documents and Settings directory, but
>>> what about registry/.SAM file/etc.? Any experience, or is this just a
>>> non-starter?
>>>
>>
>>
>
>

[coderer@gmail.com]

I think there has been some miscommunication. When I said
"EWF-protected, read-only XPe system", I meant that the media we're
booting from is read-only. Thus, comitting *any* changes at all to the
boot volume would be out of the question. That's why I considered this
to be a probably-intractable issue. I think adding users *always*
requires a registry update, and probably a .SAM update as well, neither
of which we could do, unless we could "include" files from another
volume. If that's possible, it's certainly beyond my current
knowledge. Thanks, though, for all the suggestions.

[KM]

Ahh.. I didn't think that you meant "really" read-only media :-)

Then you can try another trick that could be not good implementation performance wise but still a solution for you.
Create a script or an application that will read a special file on a non-read-only volume of the system. The file should contain the
user names and settings of the user accounts to be created. It can also specify the locations of the user profiles, etc. (basically,
the file is a replacement for SAM database and some registry keys)
The application that reads these user settings will create new user accounts on fly. There is an API for that, or it can launch a
tool like "net USER" or command line version of user manager (cusrmgr.exe from Resource Kit). Basically, no reboot required to have
an account created and registered.
The application should be launched before first logon, e.g. as a service.

--
KM,
BSquare Corp.
www.bsquare.com


>I think there has been some miscommunication. When I said
> "EWF-protected, read-only XPe system", I meant that the media we're
> booting from is read-only. Thus, comitting *any* changes at all to the
> boot volume would be out of the question. That's why I considered this
> to be a probably-intractable issue. I think adding users *always*
> requires a registry update, and probably a .SAM update as well, neither
> of which we could do, unless we could "include" files from another
> volume. If that's possible, it's certainly beyond my current
> knowledge. Thanks, though, for all the suggestions.
>

[Coderer]

Ha! Didn't really think of that. Of course, that means I'd also have
to write a tool to update the "special file", as you say, when the
admin adds an account, but it should work. Only one tiny hurdle to
overcome: how to get around storing passwords in plaintext? They could
be kept encrypted, but storing the private key anywhere on the system
is bad form, and it's supposed to be standalone.... tricky. It's a
clever hack, but I'm going to have to think about it. Thanks for the
suggestion.


P.S. Any pointers on learning about writing system services? I've
used some shareware toolkit for making Java system services, but I
don't know the first thing about writing them "from scratch".

[Gordon Smith \(eMVP\)]

Coderer wrote:
> P.S. Any pointers on learning about writing system services? I've
> used some shareware toolkit for making Java system services, but I
> don't know the first thing about writing them "from scratch".

There is code for a sample service on the XPE cd (message box interception
service). It's pretty straightforward.

--
Gordon Smith (eMVP)
-- Avnet Applied Computing Solutions