EWF and Rapport Scripting

  • This topic is empty.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #3501
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    Hi All,

    I’m currently trying to roll out some packages that make changes to the HKLM registry branch using rapport scripts, except the changes that are made to the HKLM registry branch are being dropped on reboot. After some investigation, I discovered that EWF is only being disabled on D: drive, which is where the package files need to go to, and is being left enabled on C: drive, which is obviously where the registry lives. Was wondering if there is anything special I need to put in the script so that EWF is disabled on both drives as opposed to just D: drive.

    Thanks,

    Gavin

    #16244
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    OK,

    Have found a work-around. I’ve added the following line to my script after I make the registry changes:

    EX "ewfmgr c: -commit" "+30"

    Is there a better way to do this, because I figure this is probably not best practice…. 🙂

    Thanks,

    Gavin

    #16249
    ConfGen
    Keymaster
    • Total Post: 11485
    • Jedi Master
    • ★★★★★★★

    What kind of package? Antivirus? Why do you have a D: drive and more interesting why are you still using the old EWF instead of the newer File-Based WF?
    If any application has to store data on C: you always would have to either disable/enable the WF or in your case (EWF) do a commit.

    CG

    #16253
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    Not Antivirus (don’t really see the need for it to be honest), just one of our older software packages that won’t run on Citrix very well. As for D: drive, I’m fairly sure that was included with the standard build that the unit shipped with (which is a 9450xe). Just seems a bit weird that rapport would not disable the write filter on C: drive as well, as the registry lives there, which is something that a lot of packages would have to deal with.

    What do you mean by File-Based WF btw? Is that similar to the EWF Disk Mode? And is it possible to upgrade a 9450 without having to have the ability to build Windows XPe from scratch?

    Thanks,

    Gavin

    #16256
    ConfGen
    Keymaster
    • Total Post: 11485
    • Jedi Master
    • ★★★★★★★

    Standard build were never created with a D. drive, so that is something has has been done in your house.
    Normally if you send a script to a client via WDM, WDM will check the status of the WF and disable it if needed. So no idea why WDM isn’t doing that in your case.
    FBWF is the newer write filter that is included in all newer builds. Upgrading a XPe unit will always delete the entire file and partition structure. So you would have to create everything again from scratch.

    CG

    #16261
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    It is entirely possible that the build has been customized, but am not overly sure as it wasn’t done by me. Just to re-iterate the earlier questions, I shouldn’t run into any issues if I use “ewfmgr c: -commit”?

    Also, is FBWF a Microsoft Product that’s meant to replace EWF?

    Gavin

    EDIT: Just had a thought, does EWF/Rapport HAgent have options that can be customized to tell them whether or not to unlock C: drive?

    #16264
    ConfGen
    Keymaster
    • Total Post: 11485
    • Jedi Master
    • ★★★★★★★

    I shouldn’t run into any issues if I use “ewfmgr c: -commit”?

    That is 100% correct

    FBWF is the replacement of EWF.

    Check for a registry key ReportWFas = 0 in HKLMSOFTWARERapportHAGENT
    If this exist, then the WDM agent does not report the WF status to WDM and you would have to disable it manually.

    CG

    #16266
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    OK, thanks. Will give that a go when I get to work

    #16270
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    OK, Had a look for that value in the registry, but it did not exist. I also attempted to create it and set its value to 1, but it made no difference. I’m figuring there must be options/commands somewhere which tell the hagent what to do when it needs to disable the write filter, because I have a bunch of old scripts which I’m guessing were used on a previous build with a different write filter (venturcom or something) that modify c: drive without any “commits”. Does anyone know of any such options?

    Gavin

    Edit: I just tried one of my new scripts on the previous build that uses the different write filter and it works fine. So it would seem to be an issue with the Rapport HAgent??

    #16275
    ConfGen
    Keymaster
    • Total Post: 11485
    • Jedi Master
    • ★★★★★★★

    What WDM version and what HAgent version are you running?

    CG

    #16278
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    Hi,

    The WDM Version is 4.7.2 and the HAgent Version is 4.0.5.5. I have also tried upgrading the HAgent to the version that ships with WDM 4.7.2, which I think is 5.1.1.10 (going by the file version) with no luck.

    Gavin

    #16290
    ConfGen
    Keymaster
    • Total Post: 11485
    • Jedi Master
    • ★★★★★★★

    Why does the HAgent upgrade fail? Even if you disable the WF before deplaying the image?

    CG

    #16291
    gavin0001
    Member
    • Total Post: 23
    • Regular Joe
    • ★★

    Sorry, I worded that poorly. I have upgraded the HAgent to the latest version by adding commit lines to the script, and then tried running my package again without the commit lines, and it still didn’t work. So upgrading to the latest hagent didn’t fix the problem.

    Gavin

    #16294
    karaziel
    Member
    • Total Post: 74
    • Back Stage Pass
    • ★★★★

    Could be bad FW image on the device.
    In the WDM GUI what does the WF status report as? (Enable/Disabled)

    Could also be some leftover info in the WDM DB from a previous failed update in an older version WDM.

    If WDM “thinks” WF is disabled it won’t disable WF automatically. If it recognizes WF is enabled then it should tell the device to disable WF and track the status in the database. Its possible it still thinks the device is mid update from previous job. This could all be confirmed with a network trace capturing the HTTP traffic between server and client. (hint: wireshark)

    Does this affect all devices, or just a specific set of devices? Have you tried updating the image to a newer FW?

    -k

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.