I’m upgrading from 9.5.2.56 to 9.5.7. So I guess it would be better to go to 9.5.5 first?
No, you can upgrade to 9.5.7 directly, but will have to do it manually (not via fixlet) since you’re below 9.5.5.
Got that part just wanted to be clear if we upgrade to 9.5.7 we should get the updated WEB UI and will be able to use auto patch
The updated WebUI configuration that directly accesses the database is available in 9.5.5 and higher platform versions. You need to use the task “Deploy WebUI Database Configuration” (ID #2687) (after upgrading the platform) to enable the new config for auto patch.
2 Likes
Looking for some examples of the new “Run As User” command, I don’t see it when I go to compile a Task, I only see run. This functionality is supposed to be in 9.5.7. Is there a special way to invoke this command? Thanks.
Take a look at the developer documentation. You need to override the run or wait command.
https://developer.bigfix.com/action-script/reference/execution/override.html
2 Likes
The IBM BigFix team is releasing a Windows Agent and Relay binary refresh for BigFix 9.5 Patch 7 (v9.5.7.94).
This version includes all of the previously announced 9.5.7 functionality and adds support for the BigFix Agent and Relay on Windows 10 Fall Creators Update (release id 1709).
IBM recommends upgrading any existing v9.5.7.90 Agents and Relays to v9.5.7.94 for any systems that are currently running the Windows 10 Fall Creators Update. The recommended environment will have v9.5.7.94 Windows Agents and Relays reporting to v9.5 Server.
Actions to Take
- Upgrade any current 9.5.7 Windows Agents and Relays using the 9.5.7 upgrade Fixlets as soon as possible.
The upgrade Fixlets for the Agents and Relays are available in BES Support version 1371 (and later).
Note: This release includes an updated version of the upgrade Fixlets, but the Windows Installation Generator on support.bigfix.com will still contain the older Windows Agent binary to allow users to install the original version of v9.5.7.90. Complete coverage of all the Agents installation methods will be available starting from 9.5 Patch 8.
Can you clarify the following:
Question 1.
Is it required to upgrade the relays ONLY if they are running on Windows 10 Build 1709
OR
The relays should be UPGRADED to 9.5.7.94 BEFORE deploying the agent upgrade REGARDLESS of what OS the Relays are running?
Question 2.
Can I download the 9.5.7.94 Windows client installer from http://software.bigfix.com/.../.../.../BigFix-BES-Client-9.5.7.94.exe as a standalone installer and use this with new installs with our masthead OR is this a UPGRADE ONLY executable?
It is only required for the relays that are running Win10 FCU. And, yes, you can use that installer for new agent installs with your masthead.
TY for the confirmation Steve.
And for those of us at 9.5.5 for our BES Infrastructure? We have no relays on Win10. Are we supposed to upgrade any Win10 1709 endpoints to 9.5.7.94 even though our Infrastructure is at 9.5.5?
Yes, that is correct
We are running 9.5.2.56 and are upgrading to 9.5.7 in a month and only have about 6 users testing 1709 would they be able to update the BES client to 9.5.7.94? for it to work with 1709
Yes, that is equivalent to what Alexa and sbl asked.
Based on my testing, it seems like it is not possible to use the new “runas” functionality for our use case (below). Has this been mentioned before? I assumed our use case was pretty typical, but perhaps it’s not.
- Used for software installs (which require admin privileges to install)
- Software install requires user input (UI needs to be displayed to user)
- Software install does NOT require any specific user to be associated with it (meaning we want the program to run under the context of the current user, but with elevated permissions)
Knowing this use case, you can see that we obviously don’t have a specific domain user / admin account that we use for installs, so we don’t need the “runas=localuser” ability (which requires a specified password to run elevated) – we really just need a modified form of the “runas=currentuser” function, allowing it to run elevated.
FYI we are currently using SCCM to cover this use case, but our goal is to get rid of SCCM entirely so this is a requirement for us to be able to accomplish that.
If you don’t require the install to run in user context (i.e. don’t need access to HKEY_CURRENT_USER registry hive), but have some UI displayed to the user, then you can use the following override commands to give the logged on user system authority for the specific wait command:
override wait
runas=localuser
user={name of logged on user}
password=system
If you do need user context, then you can use any arbitrary user that you have the password for, and direct the UI to the current user via targetuser. The following example runs the command as the user DOMAIN\user1, giving it admin authority, and shows any UI from the command to the currently logged on user:
override wait
runas=localuser
user=DOMAIN\user1
password=required
asadmin=interactive
targetuser={name of logged on user}
3 Likes
Thank you Steve! I was able to use a variation of your first combination to get it working for us. Unfortunately the 2nd one would never work in our environment because we have RequreSmartCard set on all our machines (meaning that passwords won’t authenticate). Do you know if there are plans to get that type of scenario covered in the future? Essentially just an elevation of runascurrentuser.
As an (admittedly ugly) workaround, you can take advantage of the fact that you don’t have to reboot to enable/disable the “force smart card” option.
You could, in a single action, disable the “force smart card” option in the registry, run your elevated process, and then turn the smartcard requirement back on.