When the Access Broker service starts it attempts to contact the Portal and register itself for use. The service will fail to start if this process can't complete.

• Confirm that the Access Broker VM can reach the public internet. The Access Broker service must be able to contact the portal over HTTPS in order to start.
• Confirm that the Access Broker certificate is valid for Client Authentication and Server Authentication. The Access Broker and Portal perform mutual certificate authentication upon establishing a connection. If the Access Broker certificate is not valid for Client Authentication the mutual certificate authentication will fail.

• You need to install the .NET Framework version 4.8 in your Access Broker servers see Installing .NET Framework 4.8 and try re-install the AB agent.

The steps to add support for TLS 1.2 on a Windows Server and install .NET Framework 4.8 Runtime.

1. Press Win + R to open the "Run" dialog.
2. Type regedit and press Enter to open the Registry Editor.

1. In the Registry Editor, navigate to the following key:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
   

1. Right-click on the "Protocols" key.
2. Choose New and then Key.
3. Name the new key as TLS 1.2.

1. Right-click on the TLS 1.2 key.
2. Choose New and then Key.
3. Name the new key as Client.
4. Right-click on the Client key.
5. Choose New and then DWORD (32-bit) Value.
6. Name the new DWORD as DisabledByDefault.
7. Double-click on DisabledByDefault and set its value to 0.
8. Right-click again on the Client key.
9. Choose New and then DWORD (32-bit) Value.
10. Name the new DWORD as Enabled.
11. Double-click on Enabled and set its value to 1.
12. Repeat steps 3 to 11 for the Server key.

1. After making the changes, close the Registry Editor.
2. Restart the Windows Server for the changes to take effect.

Download the Installer from the official Microsoft .NET Framework 4.8 download page.

1. Locate the downloaded installer file (ndp48-web.exe).
2. Double-click the installer to run it.

1. The .NET Framework 4.8 installation wizard will appear.
2. Read and accept the terms of the license agreement.
3. Choose the installation path or keep the default path.
4. Click Install to begin the installation process.

1. Once the installation is complete, the wizard will display a completion message.
2. Restart your computer to ensure that the changes are applied.

You have successfully enabled TLS 1.2 support on your Windows Server and installed .NET Framework 4.8 Runtime. Now try installing Access Broker installer.

• Confirm that the machine running the Client has internet connectivity.

Upon starting up the Client requests a list of available Access Brokers from the Portal. If no Access Brokers are available the Client can't authenticate the user session.

• Confirm that an Access Broker has been installed and that the service is running.
• Confirm that an Access Broker has been marked as enabled in the Agents > Access Brokers section of your admin Portal.

The Client must successfully connect to and perform domain authentication with an Access Broker prior to fetching a user's storage profile from the Portal.

• Confirm that network connectivity exists between the Client and the Access Broker on the port selected during installation. Firewall rules must be in place to allow inbound TCP connections to the Access Broker on the selected port.
• Confirm that the Client machine is joined to an AD domain.
• Confirm that the Access Broker VM is joined to an AD domain.
• If your institution runs multiple domains, confirm that the Client and Access Broker machines are joined to the same domain, or that a trust exists between the domains to which they are independently joined.

When a user logs into the Portal the institution's IdP sends a username with which we associate the user's storage profile. When the Client attempts to fetch that profile it authenticates with an Access Broker, at which time the user's AD User Principal Name (UPN) is resolved. The UPN resolved by the Access Broker match the username sent by the IdP in order for the Client to receive the appropriate storage profile. If they are not the same the Portal will not return a storage profile and the user will be prompted to create one. In that case will need to modify your IdP configuration to send usernames in the same format as AD UPNs.

To determine the username sent by your IdP:

1. Browse to https://your-kumo-portal/Claims.
2. Note the value in the Username field. This is the username sent by the IdP.

To determine the UPN resolved by your Access Broker:

1. Launch a Kumo client as a user for whom you'd expect a storage profile to exist.
2. RDP to your Access Broker server
3. Open Windows Event Viewer and browse to the Application logs.
4. Filter to logs for the service KumoAccessBrokerAgent
5. Look for log entries of the format "Successfully completed task 'fetch authentication token for UPN'"
6. Of those log entries find that appears to correspond with your account. This is your AD UPN.

By default a startup item is created for all users that will automatically launch the Client on login. In some system configurations the startup item will be ignored and the Client will not be launched. You can confirm that the Client has launched by checking for a Kumo Client process in the Task Manager.

It's also somewhat common for the client to be launched with elevated privileges, even if the user is not logged in as an administrator. As a result the storage can be mounted in such a way that it is not visible/available in the user's desktop session. The Kumo Client is able to detect that this is happening and will log it to the Windows Application log with the message, The Kumo client has been launched with elevated permissions. If the user's desktop session is running with normal permissions then the drives mounted by Kumo will not be visible in Windows Explorer.

The best way that we've found to resolve both of these scenarios is to launch the Client using a Scheduled Task that executes immediately after login. Please refer to Client Setup: Windows for information on how to create and configure this Scheduled Task.

This occurs when our vended virtual file system driver does not get installed properly. This can be resolved by uninstalling and reinstalling the client on the affected machine.