EWF and Terminal Server Licensing



MS
07-09-2005, 09:24 PM
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
07-09-2005, 09:24 PM
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


"MS" <mageshpatvxldotnet> wrote in message
news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
> 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
>
>
>

Slobodan Brcin \(eMVP\)
07-09-2005, 09:24 PM
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" <sfigg@arrow.com.NOSPAM> wrote in message
news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
>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
>
>
> "MS" <mageshpatvxldotnet> wrote in message
> news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
>> 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
07-09-2005, 09:24 PM
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

"Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
news:uqp23AzVFHA.2420@TK2MSFTNGP12.phx.gbl...
> 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" <sfigg@arrow.com.NOSPAM> wrote in message
> news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
> >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
> >
> >
> > "MS" <mageshpatvxldotnet> wrote in message
> > news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
> >> 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
> >>
> >>
> >>
> >
> >
>
>

KM
07-09-2005, 09:24 PM
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

>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
>
> "Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
> news:uqp23AzVFHA.2420@TK2MSFTNGP12.phx.gbl...
>> 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" <sfigg@arrow.com.NOSPAM> wrote in message
>> news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
>> >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
>> >
>> >
>> > "MS" <mageshpatvxldotnet> wrote in message
>> > news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
>> >> 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
07-09-2005, 09:24 PM
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" <konstmor@nospam_yahoo.com> wrote in message
news:#Lh$94zVFHA.2128@TK2MSFTNGP15.phx.gbl...
> 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
>
> >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
> >
> > "Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
> > news:uqp23AzVFHA.2420@TK2MSFTNGP12.phx.gbl...
> >> 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" <sfigg@arrow.com.NOSPAM> wrote in message
> >> news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
> >> >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
> >> >
> >> >
> >> > "MS" <mageshpatvxldotnet> wrote in message
> >> > news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
> >> >> 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
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

KM
07-09-2005, 09:24 PM
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

> 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" <konstmor@nospam_yahoo.com> wrote in message
> news:#Lh$94zVFHA.2128@TK2MSFTNGP15.phx.gbl...
>> 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
>>
>> >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
>> >
>> > "Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
>> > news:uqp23AzVFHA.2420@TK2MSFTNGP12.phx.gbl...
>> >> 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" <sfigg@arrow.com.NOSPAM> wrote in message
>> >> news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
>> >> >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
>> >> >
>> >> >
>> >> > "MS" <mageshpatvxldotnet> wrote in message
>> >> > news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
>> >> >> 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
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

MS
07-09-2005, 09:24 PM
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

"KM" <konstmor@nospam_yahoo.com> wrote in message
news:urQFCd3VFHA.2256@TK2MSFTNGP14.phx.gbl...
> 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
>
>> 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" <konstmor@nospam_yahoo.com> wrote in message
>> news:#Lh$94zVFHA.2128@TK2MSFTNGP15.phx.gbl...
>>> 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
>>>
>>> >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
>>> >
>>> > "Slobodan Brcin (eMVP)" <sbrcin@ptt.yu> wrote in message
>>> > news:uqp23AzVFHA.2420@TK2MSFTNGP12.phx.gbl...
>>> >> 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" <sfigg@arrow.com.NOSPAM> wrote in message
>>> >> news:O7GrLWyVFHA.2644@TK2MSFTNGP10.phx.gbl...
>>> >> >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
>>> >> >
>>> >> >
>>> >> > "MS" <mageshpatvxldotnet> wrote in message
>>> >> > news:eqdpbHuVFHA.628@tk2msftngp13.phx.gbl...
>>> >> >> 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
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>


EWF and Terminal Server Licensing