Additional administration commands

.\BESAdmin.exe /service { arguments}

converttoldapoperators
createuser
deleteuser
edituser
findinvalidsignatures
minimumSupportedClient
minimumSupportedRelay
resignsecuritydata
rotateserversigningkey
setproxy
updatepassword

converttoldapoperators

You can convert local operators to LDAP operators, so that they can log in with their LDAP credentials. Optionally you can use the -mappingFile argument to specify a file, the mapping file, where each line has the name of the user to convert, followed by a tab, followed by the name of the user in LDAP/AD. Specify the name using the same format that the user will use to log into the console, domain\user, user@domain, or user. If you do not specify a mapping file, all users are converted assuming their name in LDAP/AD is the same as their local user name.

The syntax to run this service is:

.\BESAdmin.exe /convertToLDAPOperators [/mappingFile:<file>]

createuser

You can create accounts for operators that access the Console.

The syntax to run this service is:

.\BESAdmin.exe /createUser:<UserName> 
/userPassword:<UserPassword> 
/masterOp:<yes|no> 
/customContent:<yes|no> 
/showotherusersactions:<yes|no>
/unmanagedAssetPrivilege:<all|none|scanpoint>

Optionally you can specify the following parameters:

masterOp

Specifies whether the user is a master operator. The default value is no. You can specify the edituser parameter to modify user's allowed operations.

customContent

Specifies whether the user can create custom content. The default value is yes.

showotherusersactions

Specifies whether the user can see other user's actions that affect the computers they manage. The default value is yes.

unmanagedAssetPrivilege

Defines what unmanaged assets the user can see. The default value is scanpoint.

deleteuser

You can mark as deleted a non-master operator. When you run this command the operator instance is removed from the database but the content that the operator created is not removed.

The syntax to run this service is:

.\BESAdmin.exe /deleteUser:<UserName>

editUser

The syntax to run this service is:

.\BESAdmin.exe /editUser:<UserName> 
/loginPermission:<always|never|role>
/customContent:<yes|no> 
/showOtherUsersActions:<yes|no>
/unmanagedAssetPrivilege:<all|none|scanpoint>

You can specify the same parameters supported for createUser a part from masterOp that is supported only by createUser, and loginPermission that is supported only by editUser and has the following behavior:

loginPermission

Specifies when the user is allowed to log in. The default value is always which means that the user is always allowed to log in. The value never means that the user is not allowed to log in at all. The value role means that the user can log in if he is a member of a role. This parameter is used to disable operators login, or to assign a role to an LDAP group and allow anyone in that LDAP group to log in.

findinvalidsignatures

You can check the signatures of the objects in the database by specifying the following parameters:

-resignInvalidSignatures (optional)

Attempts to resign any invalid signatures that BESAdmin finds.

-deleteInvalidlySignedContent (optional)

Deletes contents with invalid signatures.

For additional information about invalid signatures see http://www-01.ibm.com/support/docview.wss?uid=swg21587965.

The syntax to run this service is:

.\BESAdmin.exe /findinvalidsignatures 
[ /resignInvalidSignatures | /deleteInvalidlySignedContent ]

minimumSupportedClient

This service defines the minimum version of the BigFix Agents used in your BigFix environment.

Note: Based on this setting, the BigFix components can decide when it is safe to assume the existence of newer functions across all the component in the deployment. Individual agent interactions might be rejected if the interaction does not comply with the limitations imposed by this setting.

The currently allowed values are:

• 0.0 which means that no activity issued by BigFix Agents earlier than V9.0, such as archive files and reports uploads, are prevented from running or limited. This behavior applies also if the minimumSupportedClient service is not set.
• 9.0 which means that:
  • Unsigned reports, such as the reports sent by BigFix Clients earlier than V9.0, are discarded by FillDB.
  • The upload of an unsigned archive file generated on a BigFix Client earlier than V9.0, by an archive now command for example, fails.

If you ran a fresh installation of BigFix V9.2.11 or later, the minimumSupportedClient is not set and so the BigFix Server the can accept archive files and reports uploads from all the Agents, regardless of their version.

The current value <VALUE> assigned in your environment to the minimumSupportedClient service is displayed in the line x-bes-minimum-supported-client-level: <VALUE> of the masthead file.

The syntax to run this service is:

.\BESAdmin.exe [/sitePvkFile=<path+license.pvk>] [/sitePassword=<password>] 
/minimumSupportedClient=<version>.<release>

If you omit [/sitePvkFile=<path+license.pvk>] [/sitePassword=<password>], you will be requested to enter the site key and password in a pop-up window.

For example, if you want to state that Agents earlier than V9.0 are not supported in your BigFix environment, you can run the following command:

.\BESAdmin.exe /minimumSupportedClient=9.0

minimumSupportedRelay

You can use this service, added with BigFix V9.2.12, to enforce specific criteria affecting the BigFix Agent registration requests. If this service is enabled appropriately, V9.2.12 Agents can continue to register to the V9.2.12 BigFix environment if their registration requests are signed and sent across the Relays hierarchy using the HTTPS protocol.

Note: Based on this service, the BigFix components can decide when it is safe to enable newer functions across all the component in the deployment. Individual agent interactions might be rejected if they do not comply with the limitations imposed by this setting.

The currently allowed values are:

• 0.0.0 which means that the BigFix Server accepts and manages:
  • Signed and unsigned registration requests coming from BigFix Agents.
  • Registration requests delivered from BigFix Agents using the HTTP or the HTTPS protocols.
  This behavior applies by default when you upgrade from previous versions to BigFix V9.2.12 or later. In this case the minimumSupportedRelay service is not added automatically to your configuration during the upgrade. Note that this value is not displayed when you run the query to see the current value assigned in your environment to the minimumSupportedRelay service.
• 9.2.12 which means that:
  • The BigFix Server enforces that registration requests coming from BigFix Agents V9.2.12 or later must be properly signed.
  • The BigFix Server and the Relays V9.2.12 or later enforce the use of the HTTPS protocol when exchanging BigFix Agent registration data.
  These are side effects of enforcing this behavior:
  • BigFix Agents earlier than V9.0 cannot send registration requests to the BigFix Server because they cannot communicate using the HTTPS protocol.
  • Because BigFix Relays with versions earlier than V9.2.12 cannot handle correctly signed registration requests, any BigFix Client using those Relays could be prevented from continuing to register, or could fall back to a different parent Relay or directly to the Server.

If you ran a fresh installation of BigFix V9.2.12 or later using a License Authorization file, be aware that the side effects listed above apply to your BigFix deployment because, in this particular installation scenario, the minimumSupportedRelay service is automatically set to 9.2.12 by default.

The current value <VALUE> assigned in your environment to the minimumSupportedRelay service is displayed in the line x-bes-minimum-supported-relay-level: <VALUE> of the masthead file. You can see the current value by running the following query on the BigFix Server, using the Fixlet Debugger or the BigFix Query Application available on the BigFix WebUI:

Q: following text of last ": " of line whose (it starts with 
"x-bes-minimum-supported-relay-level:" ) of masthead of site "actionsite"

This query displays a value only when <VALUE> is set to 9.2.12; if it is set to 0.0.0, it does not display a value.

The syntax to run this service is:

.\BESAdmin.exe [/sitePvkFile=<path+license.pvk>] [/sitePvkPassword=<password>] 
/minimumSupportedRelay=<version>.<release>.<modification>

If you omit [/sitePvkFile=<path+license.pvk>] [/sitePwkPassword=<password>], you will be requested to enter the site key and password in a pop-up window.

For example, if you want that only the registration requests that are signed and carried through HTTPS are managed by your BigFix Server, you can run the following command:

.\BESAdmin.exe /minimumSupportedRelay=9.2.12

resignsecuritydata

You must resign all of the users content in the database by entering the following command:

./BESAdmin -resignSecurityData 

if you get one of the following errors:

class SignedDataVerificationFailure 
HTTP Error 18: An unknown error occurred while transferring data from the server

when trying to login to the BigFix console. This command resigns security data using the existing key file. You can also specify the following parameter:

/mastheadLocation=<path+/actionsite.afxm>

The complete syntax to run this service is:

.\BESAdmin.exe /resignsecuritydata /sitePvkLocation=<path+license.pvk>
[ /sitePvkPassword=<password> ] /mastheadLocation=<path+/actionsite.afxm>

rotateserversigningkey

You can rotate the server private key to have the key in the file system match the key in the database. The command creates a new server signing key, resigns all existing content using the new key, and revokes the old key.

The syntax to run this service is:

.\BESAdmin.exe /rotateserversigningkey /sitePvkLocation=<path+license.pvk>
[ /sitePvkPassword=<password> ]

setproxy

If your enterprise uses a proxy to access the Internet, you must set a proxy connection to enable the BigFix server to gather content from sites as well as to do component-to-component communication or to download files.

For information about how to run the command and about the values to use for each argument, see Setting a proxy connection on the server.

updatepassword

You can modify the password used for authentication by product components in specific configurations.

The syntax to run this service is:

.\BESAdmin.exe /updatepassword /type=<server_db|dsa_db>
[/password=<password>] /sitePvkLocation=<path+license.pvk> 
[/sitePvkPassword=<pvk_password>]

where:

type=server_db

Specify this value to update the password used by the server to authenticate with the database.

type=dsa_db

Specify this value to update the password used in a DSA configuration by a server to authenticate with the database.

The settings /password and /sitePvkPassword are optional, if they are not specified in the command syntax their value is requested interactively at runtime. The password set by this command is obfuscated.