Resolved issues and enhancements

Resolved issues and enhancements

This 5.7.2.5 release of Foglight for Office 365 accompanies the release of Foglight Evolve 9.1 and Foglight for Virtualization, Enterprise Edition 8.9.1. This release does not include any resolved issues and enhancements.

Back to Top

Upgrade and compatibility

Upgrade and compatibility

The latest version of Foglight for Office 365 is 5.7.2.5. You can upgrade to version 5.7.2.5 of Foglight for Office 365 from Foglight for Exchange 5.7.2.2 or Foglight for Office 365 5.7.2.3 and later.

Note: When upgrading a stand-alone Foglight for Office 365 from a version earlier than 5.7.2.3, the license must be updated. Contact your Quest Account Manager for your new license.

To upgrade the Foglight for Office 365 to the latest version:

1. Deactivate all of the Office 365 agents.
2. Install version 5.7.2.5 of Foglight for Office 365. For details, see Installation instructions.
3. Deploy the agent package to each Foglight Agent Manager that hosts an Office365 agent instance and wait for the version to update.
   Note: This may take two to three refresh cycles.
4. From the navigation panel, navigate to Dashboards > Office365 > Office365 Environment > Administration tab. In the Agents view select the Office365 agents that you want to upgrade, and click Upgrade Agent.
   Note: You can specify the lockbox when upgrading the agents. The credentials for the existing agents are updated automatically. 
   
5. Verify the agent properties and update the properties and collection intervals as required.
6. Activate the agents and start data collections.

The following is a list of product versions and platforms compatible with this release.

Back to Top

System requirements

System requirements

Before installing Foglight for Office365, ensure your system meets the following minimum hardware and software requirements:

Back to Top

Prerequisites

Prerequisites

The following prerequisite conditions must be in place in order to successfully initialize an Office 365 agent. Failure to meet these prerequisites may result in missing metrics in Foglight for Office 365 dashboards.

Important: All prerequisite steps must be completed on the ADFS server as well as the Active Directory® server because the Office365 agent collects information from the Active Directory server and requires access permissions.

Note: The Remote Access Diagnostics utility, provided with this cartridge, checks the connectivity between the Foglight Agent Manager (FglAM) and Active Directory and ADFS servers that are being monitored. It also tests for the prerequisite conditions that must be met in order to initialize an Office 365 agent. This utility requires .NET® 2.0 libraries to run. For more information on running the Remote Access Diagnostics utility, see the Remote Access Diagnostics User Guide.

Account privileges

Office 365 account privileges:

Note: Make sure to give minimum required privilege to your agent; otherwise this agent cannot start data collection.

ADFS account privileges:

• ADFS server Local Administrator privilege (DCOM, WinRm)

Office 365® account privileges:

• Global administrator when consent the application permission
• Monitoring with the following privileges (Office 365 report):
  • Billing administrator
  • Password administrator
  • Service administrator
  • User management administrator
  • Exchange administrator

DCOM prerequisites for the ADFS server

1. Enable the Distributed COM (DCOM) on the ADFS server:
   1. Click Start | Run.
   2. In the Run dialog, enter dcomcnfg and click OK.
   3. Expand Component Services and then Computers.
   4. Right-click the My Computer object and select Properties.
   5. On the Default Properties tab, check the Enable Distributed COM on this computer option.
      • Select "Default Authentication Level" as "Connect.
      • Select "Default Impersonation Level" as "Identify".
2. The Remote Registry Service must be running on each ADFS server being monitored by Foglight for Office 365, to allow agents remote access to the registry.
   
3. The ADFS account specified in the agent properties must have Full Control permissions on following registry keys:
   • HKEY_CLASSES_ROOT\CLSID 72C24DD5-D70A-438B-8A42-98424B88AFB8 (Windows Script Host Shell Object)
   • HKEY_CLASSES_ROOT\CLSID 76A64158-CB41-11d1-8B02-00600806D9B6 (WBEM Scripting Locator)
   • HKEY_CLASSES_ROOT\CLSID 0D43FE01-F093-11CF-8940-00A0C9054228 (Windows Script FileSystem Object)
     
     For a 64-bit OS, also grant the permissions for these two additional registry keys
   • HKEY_CLASSES_ROOT\Wow6432Node\CLSID 72C24DD5-D70A-438B-8A42-98424B88AFB8
   • HKEY_CLASSES_ROOT\Wow6432Node\CLSID 76A64158-CB41-11D1-8B02-00600806D9B6
   • HKEY_CLASSES_ROOT\Wow6432Node\CLSID 0D43FE01-F093-11CF-8940-00A0C9054228
     
     Note: For instructions on how to configure the registry keys, see the To grant permissions on the registry keys section.

To grant permissions on the registry keys:

1. Log in to the ADFS server with an Administrator account that you are comfortable having ownership over these keys.
2. Start the Windows Registry Editor (run regedit.exe).
3. If asked to allow the Regedit program to make changes to the computer, click Yes.
4. Navigate to the registry item: HKEY_CLASSES_ROOT\CLSID\{clsid} or HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{clsid}, as necessary.
5. Right-click the registry key and select Permissions.
6. Click Advanced.
7. Open the Owner tab.
8. In the Change Owner to box, select one of the following entries:
   • the user account that is used by the ADFS agent
   • the administrative group for the account you currently belong to
9. Select the Replace the owner on subcontainers and objects check box.
10. If the account is not listed, click Other user or groups to add the account.
11. Click OK.
12. Under Group or user names, select the account that will be specified in the agent properties. If the account is not listed, click Add to add the account.
13. Under Permission for account, select the Allow Full Control check box and click OK.
14. Close the Registry Editor.

SmbServerNameHardeningLevel in ADFS Server should be 0 (the default)

ADFS servers that have to be accessed by clients not supporting GSS authentication must have SmbServerNameHardeningLevel set to 0 (the default). For more information, see http://support.microsoft.com/kb/2345886.

Firewall settings for the ADFS Server

Rule #1: need local ports 135, 139, 389 (or 636) and 445 opened.

Rule #2: need "Dynamic RPC" local ports opened.

For more information, see the following article: https://support.quest.com/kb/SOL85903.

Configure Windows Remote Management (WinRM)

For details about this topic, refer to the "Configuring Windows Remote Management (WinRM)" section in the Foglight Agent Manager Guide.  

Kerberos settings for the Agent Manager

The Kerberos configuration file specifies the KDC from which tickets are obtained. Operating systems sometimes have their own Kerberos configuration files. If present, the Agent Manager uses them by default. They can be found in the following locations:

•  Windows: %WINDIR%\krb5.ini which typically translates to C:\Windows\krb5.ini
•  UNIX:
  /etc/krb5.conf
  Or:
  /etc/krb5/krb5.conf

If none of these files are found, the Agent Manager attempts to create its own kerberos configuration file, based on the detected settings. The detection can only be done on Windows, so on Unix, the file is not generated. On Unix platforms, you need to create your own Kerberos configuration files to establish WinRM connections using Negotiate authentication.

The krb5.ini or krb5.conf file should contain the realm info and hostname of the KDC for this realm. For example:

[libdefaults]
default_realm = <REALM_NAME_IN_CAPS>
[realms]
<REALM_NAME_IN_CAPS> = {
kdc = <fully_qualified_kdc_name>
}
[domain_realm]
.<domain_in_lower_case> = <REALM_NAME_IN_CAPS>

Configure root certificates for the Agent Manager

Important: Starting with version 5.7.1, Foglight for Exchange trusts (by default) any certificates for secure LDAP connections, and does not require users to import the SSL certificate any longer. The only case when users need to import the certificate is when they set the vm parameter "quest.ldap.ssl.trustAnyCert" as False to disable any certificate trust.

When collecting data using LDAP through SSL communication, a new Certificate Authority must be added to the Agent Manager’s Java® Runtime Environment (JRE). The JRE includes a command-line tool keytool which can be used to add the new Certificate Authority. 

keytool -import -file <importCertPath> -alias <someName> -keystore <cacertsPath> -storepass <changeit>
keytool -list -alias <someName> -keystore <cacertsPath> -storepass <changeit>

Here are example commands that import and list a new root certificate:

<FMS_HOME>\jre\bin\keytool -import -file MySSL.cer –alias MySecuryLDAP.ca -keystore <FMS_HOME>\jre\lib\security\cacerts -storepass changeit
<FMS_HOME>\jre\bin\keytool -list -alias MySecuryLDAP.ca -keystore <FMS_HOME>\jre\lib\security\cacerts -storepass changeit

The initial password of the cacerts keystore file is changeit. System administrators should change this password and the default access permissions of this file when installing the SDK. The file can be found in the directory <FMS_HOME>\jre\lib\security\cacerts (embedded Agent Manager) or <FglAM_HOME>\jre\<JRE_VERSION>\jre\lib\security\cacerts (external Agent Manager).

Note: The certificate file that you want to import should be the public certificate for the Certificate Authority that signed the server's SSL certificate, not the SSL certificate itself. The Agent Manager must be restarted for the certificate to take effect. If security LDAP is enabled when creating the Exchange agent via the Agent Setup wizard, the root certificate also needs to be added to the Foglight Management Server’s Java Runtime Environment (JRE).

Agent must be able to reach the target host

Server objects do not appear until at least one piece of data has been collected and recorded. If communication fails completely, you will not see objects.

Configuration steps:

1. Test Ping by IP. You must be able to ping the collection target from the FglAM hosting the agent instance. If ping by IP fails, there are routing issues.
2. Test Ping by host name. A DNS server or Hosts file must be available to the FMS server in order to resolve names. If ping by host name fails, there are DNS or Hosts file issues.
3. If a Hosts file is used, it should contain an entry for each domain where hosts reside. For example:
   10.10.10.100 domain.local
   10.10.10.200 childdomain.domain.local
4. In addition, individual servers must resolve to the NetBIOS names and the FQDN. For example:
   10.10.10.101 server server.domain.local
   The Hosts file is located at %windir%\system\drivers\etc.

Additional descriptions for ADFS server host data

ADFS agents delegate Windows agents, VMware agents, or Hyper-V agents to collect host data.  ADFS agents collect host details to decide whether it is a VMware Virtual machine or a Hyper-V Virtual machine. By default, the host type is a physical machine.

• For VMware virtual machine, agents delegate VMware agents to collect host data.

• For Hyper-V virtual machine, agents delegate Hyper-V agents to collect host data.

• For physical machine, agents delegate IC agents to collect host data.

Back to Top