Hi, i have one batch file which i got from Microsoft , i want to uninstall IE11 and down to IE 8 , for this batch file is working fine while running manually but does not work from Bigfix and through failed message.
Microsoft Bat file:-
FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-11..mum /c “cmd /c echo Uninstalling package @fname && start /w pkgmgr /up:@fname /quiet /norestart”
in Bigfix
wait cmd.exe /C “c:\temp1\IE11_uninstall.bat”
What is the success criteria?
I want to downgrade IE11 to IE8 that is the default version of Windows 2008 R2.
Yes, but what is the success criteria of your fixlet?
Have you validated manually if IE11 was not removed?
Ok you mean to set the relevance of the fixlet? In the bat file which Microsoft provided there is no specific success criteria.
I have run the command into a bat file manually on the server it downgrade the Internet Explorer version to IE8 from IE11 after reboot.
Then most likely your action needs the following line to only check its success after a reboot
action requires restart
Additionally if your action has NO relevance and you are just targeting, you may need to make it a “task” which says to only be successful if it completes each line. An action must go non relevant in the default case for a success.
after adding action requires restart , action got completed but did not un-install Internet explorer 11
below is the script which i am using, i able to execute successfully below command manually and un-install works
delete __appendfile
appendfile @echo off
appendfile echo Your administrator is restarting the BES Relay… Please Wait…
appendfile FORFILES /P %WINDIR%\servicing\Packages /M 11..mum /C “cmd /c echo @fname && start /w pkgmgr /up:@fname /quiet /norestart”
delete IE.bat
copy __appendfile IE.bat
run IE.bat
action requires restart
Hi Alan, Can you please help on this?
This time script got completed in console but actually does not un-install IE11
The command mentioned may work if run by a “user” but remember the command is run by LOCAL SYSTEM when it is run by the client. If the command runs as SYSTEM with a helper like PSEXEC to run it that way then BigFix can also do it. If it cannot then the command would need to be altered.
I don’t know the specific commands that you are using so I can’t be of help with them specifically.
We can’t correctly read your script. Please edit the post, highlight the batch script. and click the “Preformatted Text” formatting icon (icon looks like </> )
There are special characters in there that don’t look correct when rendered via Markup.
Also, since you’re using “run” and not “wait”, the BigFix Action will not wait for the script to finish executing before moving on to another action (the batch script continues executing in the background). If you have any other installations running, you can get into a blocking condition where one of the setup processes will fail because another installation is still executing.
// Enter your action script here
download http://server1:52311/stage/IEUninstall/IE11_uninstall.bat
delete __appendfile
appendfile if not exist c:\temp1 mkdir c:\temp1
delete foldercreate.bat
copy __appendfile foldercreate.bat
dos foldercreate.bat
copy __Download\IE11_uninstall.bat “c:\temp1\IE11_uninstall.bat”
waithidden cmd.exe /C “start /min c:\temp1\IE11_uninstall.bat”
action requires restart
====================================
` IE11_uninstall.bat file
cd C:\temp1
FORFILES /P %WINDIR%\servicing\Packages /M 11..mum /C “cmd /c echo @fname && start /w pkgmgr /up:@fname /quiet /norestart” `
I just updated the command this into my BES Action and it worked well.
// Disable wow64 redirection on x64 OSes
action uses wow64 redirection {not x64 of operating system}
Great to hear! Wow64 redirection strikes again…
Yes whenever i see there is a script related to OS then i face this issue sometime.
The BigFix client is a 32-bit application. When run on a 64-bit version of Windows, by default several system paths are “redirected” transparently by the OS - which is how 32-bit applications continue to run normally on the 64-bit system.
When a 32-bit application is coded to read/write to “C:\Program Files”, it is redirected to “C:\Program Files (x86)”. Likewise, when it reads/writes to the “HKEY_LOCAL_MACHINE\Software” registry key, it is redirected to “HKEY_LOCAL_MACHINE\Software\Wow6432Node”.
C:\Windows\System32 is also redirected to C:\SysWOW64.
By default the BigFix client respects the redirection; so older Fixlets written for 32-bit systems work as they did before. A 32-bit program installed on 64-bit Windows ends up installed at “C:\Program Files (x86)”, and a BigFix Fixlet written to find it in “C:\Program Files” will still work as it did before (because Program Files was redirected to Program Files (x86)).
To see the “native” Program Files, System32, HKLM\Software, etc. the BigFix Action Script command “action uses wow64 redirection false” is used to break out of the 32-bit redirection. In Relevance, the “native system folder”, “system x32 folder”, “system x64 folder”, “native program files folder”, “program files x32 folder”, “program files x64 folder”, “native registry”, “x32 registry”, and “x64 registry” all deal with the 32-bit folder/registry redirections.
Ok, got it , thanks for the nice explanation. is IBM is thinking of to create BESClient x64 or x32 is ok ?
To be clear, I don’t work for them; @AlanM may be able to answer.
Last I recall it being discussed, it was “probably not”. There’s not a real motive to write a 64-bit native client; the BigFix client shouldn’t be doing any heavy processing that would benefit from 64-bit computing; in fact the BES Client is already intentionally coded to be single-threaded and throttles its CPU use to have a smaller system footprint.
If a 64-bit client were added, I’d imagine they still want the inspectors and action script to behave like the 32-bit version, so that they don’t have to update their existing Fixlet set, and we don’t have to code separate fixlets for 64 vs 32-bit clients.
Ok thanks…
