Sweserijnen. nl

Tag: 32-bit

  • Parameter -EnablePVADControl will sometimes not work on a 64-bit machine

    Parameter -EnablePVADControl will sometimes not work on a 64-bit machine

    Bringing back the PVAD debate for one last time.

    Reminder:

    These are the three methods of bringing back the PVAD as discussed in several blog posts and the Microsoft TechNet site. Microsoft should fix this page though as they spell Compatibility right once and then spell it as Compatability in the Note.

    1. Launch the Sequencer from a command prompt and specify: Sequencer.exe -EnablePVADControl

    2. Populate a DWORD value called EnablePVADControl in registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Sequencer\Compatibility. Setting the value to 1 will enable the PVAD field next time you launch the Sequencer and 0 will turn it back off.

    EnablePVADControl_registry_setting

    3. Use the command line sequencer and specify the -PrimaryVirtualApplicationDirectory argument against New-AppvSequencerPackage.

    Result should be that in the Sequencer you can specify the PVAD again. See below:

    EnablePVADControl_registry

    We just noticed that in AppV 5.0 SP3 the -EnablePVADControl parameter only works on a 32-bit machine. On a 64-bit machine the parameter is not picked up. However the registry setting mentioned earlier is picked up.

    Conclusion:

    If you want the PVAD option back and you are working on a 64-bit machine be sure to use the registry key and not the -EnablePVADControl parameter.

    Update:

    It has been pointed out to me this is not the default behaviour. I have tested this against two 64-bit machines and two 32-bit machines. I will test some more and hope to find the cause why the parameter is sometimes ignored. Conclusion is still valid though as the registry key always works.

  • Sequencing Google Chrome 38.0 in AppV 5.0

    It has been a while since my last blog post but I found something that’s hasn’t been blogged about or is specific enough to blog about. As far as I know…

    Last week I was asked to see if I could sequence Google Chrome 38.0 using AppV 5.0 with hotfix 4 applied. For the same customer I was also asked to see if I could sequence Google Chrome 37.0 a couple of weeks ago. The attempt with Google Chrome 37.0 failed in their VDI environment with a crash on first launch while a second launch in the same session would succesfully start Chrome. On a non-VDI machine Chrome would work without a problem. I started some basic troubleshooting looking at their user environment tool Flex+ from Immidio and the state that was saved by the sequence. While I was away for presenting at AppManagEvent and a holiday the decision was made to deliver Google Chrome 37.0 as an MSI instead of a sequence. And someone else had made the MSI.

    With the failure of starting Chrome in the VDI environment in mind I started a test installation of Google Chrome 38.0 applying the recipes of Aaron Parker and Cody Lambert that I used in the past to virtualize Google Chrome. This time I couldn’t get Google Chrome to work using these recipes.

    These are the actions I carried out during my test installation on a 32-bit Windows 7 sequencing machine provided by the customer:

    1. Install googlechromestandaloneenterprise.msi.
    2. Move all files from the C:\Program Files\Google\Chrome\Application\38.0.2125.104 folder to the C:\Program Files\Google\Chrome\Application folder.
    3. Delete the C:\Program Files\Google\Chrome\Application\38.0.2125.104 folder.
    4. Delete the C:\Program Files\Google\Chrome\Application\Installer folder.
    5. Disable two Google Update services.
    6. Disable two Google related Scheduled Tasks.
    7. Delete the C:\Program Files\Google\Chrome folder.
    8. Importing registry files to remove a pending file operation and to disable the auto updating functionality of Chrome.

    After starting Chrome I was presented with an error that chrome_elf.dll could not be found. I could get rid off this error by moving or copying this file back to the C:\Program Files\Google\Chrome\Application\38.0.2125.104 folder. Now comes the strange part, I just tried to reproduce the error on one of my own 64-bit Windows 7 machines and I couldn’t reproduce it. Maybe the bitness or the OS language (customer’s is dutch, mine is english) has something to do with that.

    Till now I haven’t found the reason for the chrome_elf.dll error.

    But after placing the chrome_elf.dll back into the versionized folder I was presented with another unexpected error, which I suspect having something to do with disabling update services and scheduled tasks.

    I ended up sequencing Google Chrome as is, without disabling updates and without following any recipe. The customer already has a Google group policy in place for the MSI version of Google Chrome that they have in production. I just delivered the group policy settings to disable Google Chrome from auto updating  to be added to the existing Google group policy. As far as I know the customer was testing Google Chrome but has abandoned version 38.0 to try and sequence version 39.0.