EWF and Terminal Server Licensing

[MS]

XPE devices using multiple license on our TS connection.

We have XPE device with EWF Enabled.

We initiate a connection from XPE to TS using RDP.

Terminal was issued temp cal from TS CAL server.

next connection terminal gets permanent CAL.

When we reboot the device and connect to Terminal server, its get issued
temp CAL again because it did not save the CAL registration during Re boot
because of EWF.

Like this it used multple license on every connection after reboot.

Is it know problem wiht EWF? is there any get around for this?

Kind Regards,

MP

 

[Scott Figg]

I don't have a fix for you, but interesting enough they talked about this
issue during one of the EWF sessions at MEDC this week in Las Vegas. The
Microsoft speaker said they hoped to have the fix out late 05 for this, it
involved "punching" a hole in the EWF so they could persist these registry
keys.

-Scott Figg

 

[Slobodan Brcin \(eMVP\)]

Scott,

Punching such hole in EWF is possible and extremely dangerous with current
XP and EWF implementation. (Even with changes to EWF this concept will be
dangerous wiht current registry implementation)

Regards,
Slobodan

 

[Scott Figg]

I guess that's why I'll wait for Microsoft to do that and I wouldn't try
it....I'm *thinking* Microsoft will present a solution that won't be
dangerous .

-Scott Figg

 

[KM]

Potential fix could be in not in "punching" a hole in EWF with regards to
the registry which may be hard to do with current EWF implementation.

But rather having EWF aware of the settings that should be persistent over
reboots.
It may again be extremety hard to implement with current EWF RAM Reg mode,
but may not be so hard with modes where EWF hidden config partition exists.
Then "some" setings may be set to be persistent and, basically, EWF could
populate them in registry reading from the hidden partition on next boot.
So, for example, hrogh ewfmgr we could supply EWF with reg.key paths that
needs to be persistent ("saved") accross reboots. EWF managers forwards
requests to EWF driver that writes the key contents to the hidden partition
either by request ("live") or on graceful shutdown. On the next boot EWF
drive reads that saved data and populate it in system or software hives.

Another implementation could in having a generic loader phase driver that
would be loaded before the EWF. That driver can again use a hidden partition
to preserve some data accross reboots.
This approach would not require any changes in EWF but some code can
definitely be "copied/pasted" from EWF.

Both approaches could use not a hidden partition but a hidden/system file to
preserve some data. If the file is a fixed size it can even live "fine" with
latest EWF (that will just commit changes to that file only), and with HORM.

Just throwing out ideas..

KM

 

[Scott Figg]

So maybe punching a hole wasn't a good term for me to use. Anyway, in case
anyone went to MEDC this week, you can download the presentation for EMB309
and see slides 29-31 they kind of explain what they are attempting to do.
For those that didn't go to MEDC, you missed a really good conference.

 

[KM]

Scott,

Well.. I can't say I missed the conference but I couldn't visit that presentation :-(

I checked the presentation now and I see what you meant. Seems like it is going to be a nice feature of EWF.
Yeah, the slide says it is going to be available at the end of 05. Let's cross out fingers

KM

 

[MS]

Its good to see your replies.

I got the same answer when i met with Microsoft last time.

Tempraory solution for this is sending unit with EWF Disabled and once the
user made the connection twice to get permanent cal, user will enable the
EWF manually.

lets wait for the update...

Thanks for your replies.

Kind Regards,

MP