- This topic is empty.
-
Posts
-
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
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
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
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
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
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?
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
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??
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
Why does the HAgent upgrade fail? Even if you disable the WF before deplaying the image?
CG
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
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
- You must be logged in to reply to this topic.