Preparation

Review all tasks to decide how you wish to proceed, and record all configuration details. Implementation of 1E can be extremely quick if all necessary preparations have taken place, and is typically performed in this order:

1. Obtain the 1E License file and ensure it includes entries for the consumer applications you have purchased.

2. Provision the 1E Web and SQL server hardware, refer to Server Provisioning.

   • Install the Windows Server OS

   • Configure Network interfaces

   • Create the server's DNS Names and Service Principal Names

   • Obtain and install the server's Web Server Certificate, for which you will need to know the server's DNS Name

   • Install IIS roles, role services and features, refer to Windows Server roles and features

3. Provision applications in the IdP.

   • Microsoft Entra ID: AAD Applications

   • Okta: Okta Applications

4. Identify and create AD Accounts and Groups, refer to Active Directory.

5. Review each of the requirements pages under .

6. Manually install clients on a few test devices, refer to Deploying 1E Client.

7. Use the 1E Verification Instruction to verify the installation, refer to Verifying.

8. Install other Instruction Definitions refer to Instructions, and from 1E Platform zip, and 1E Exchange.

9. Add the Instruction Definitions to Instruction Sets to determine their permissions, refer to the Instructions

10. Install 1E Consumers (documentation not provided here).

11. Package the 1E Client as required by your software deployment tool (see note).

12. Deploy the client to more pilot devices.

13. Pilot testing.

14. Start rollout of clients.

15. Use the SDK to begin developing your own instructions and testing your use-cases.

Details required when using 1E Server Setup to install a 1E server

The table below lists details required on each of the 1E Server Setup screens. You can review screens in the 1E Server setup page. Items marked * can wait until after installation.

Other requirements:

• Server Installation Account: Refer to Installation Accounts

• Server sizing for on-premises: Refer to On-premises installation

• Server sizing for AWS and Azure: Refer to On-premises installation

Post-installation requirements:

• 1E user permissions

• Product integration requirements

• Verifying

• Client devices preparation, refer to License file

You will need to obtain a valid license file from 1E. For more details, refer to License requirements.

Whitelisting for license activation and validation

Ensure the following URL is whitelisted: https://license-v1.1e.com

This URL must be accessible from the 1E Server during the setup and running of 1E.

The 1E license must be validated on a regular basis via internet contact with the 1E license service. The regular validation period is set when the license is requested.

For whitelisting purposes, the 1E Server (specifically the Coordinator Workflow module in Master Stack) requires an Internet connection to the 1E license service, as defined in the license file itself. If activation fails, then the system will install but not be usable until the activation is completed. an Other URL must also be whitelisted, refer to Whitelisting connections to 1E Cloud.

Upgrading

When upgrading, you are recommended to get a new license file and update your whitelist with the new URL. The old URL https://license.1e.com is suitable only for 8.0 and earlier. However, if you are upgrading and your license file has the old URL then you should also whitelist the old URL.

Code Signing Certificates

You will need your own code signing certificate, and have it registered in your 1E license, if you want to develop your own custom 1E instructions, or modify those of other authors. Instructions that are provided in the 1E Platform or downloaded from the 1E Exchange have already been code signed using the Platform and Exchange certificates from 1E. Your license controls whether you can use these instructions.

Ideally, all of your instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your license and associated with your organization's instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your license. This will then automatically activate on your 1E Server (assuming it has connection to the Internet).

An IIS Web Server should be provisioned. SQL Server can be installed on the same server or the databases can be hosted on remote SQL Server instance(s). Refer to Server sizing requirements. In addition, the 1E Server requires the following, which requires more thought and preparation:

• Network interfaces

• DNS Names and their Service Principal Names

• Web Server Certificate

• Install and configure IIS, refer to Windows Server roles and features

• Services and NTFS Security

Network interfaces

For the remote SQL Server requirement, refer to Configuring a persistent route for SQL traffic. Ensure you also consult your server, firewall, and networking teams. Cloud implementations have special configuration requirements for SQL Server and network interfaces described in Server sizing requirements.

Configuring a persistent route for SQL traffic

The following example steps can be used to configure IPv4 network routing so that a specific network interface is used for all traffic going to the specified SQL Server. The example is for a Response Stack and SQL Server on different subnets, but also works if both servers are on the same subnet.

1. On the 1E Server (single-server or Response Stack) open a PowerShell command prompt

2. The following command should resolve the name and IP Address of the SQL Server, and show the existing network route. In our example the 10.0.20.20.

   Copy

   pathping ACME-SQL02

3. If not already installed on the server, add a new interface. Configure its properties as follows:

   • Disable IPv6

   • Configure IPv4 properties and assign a static IP Address and subnet mask. In our example, these are 10.0.10.31 and 255.255.255.0

   • You do not need to configure a default gateway. You can if required, but you will receive a warning later about multiple default gateways and redundancy. However, you do need to know the default gateway for the route to the SQL Server, in our example, this is 10.0.10.1

   • Click Advanced... and click on the DNS tab. Uncheck Register this connection's addresses in DNS so that the interface IP Address is NOT registered in DNS

   • Click OK twice to save, and then Close

   • You can give the interface a name to help distinguish it from Switch interfaces. In our example, this is Interface used for SQL

     This interface must not be registered in DNS if the DNS Name of the server is a CNAME Alias for (A) Host records registered by Switch interfaces because clients need to use the DNS Name to connect to Switches. If you need this interface to be registered in DNS, then do this with a (A) Host record.

4. Enter the following PowerShell command, which provides all the details you need to confirm interfaces have been configured correctly.

   Copy

   Get-NetIPConfiguration              

5. This provides output similar to the following and tells us the interface index for the new interface. In our example, this is 7.

   Copy

   InterfaceAlias       : Interface used for SQL
   InterfaceIndex       : 7
   InterfaceDescription : Microsoft Hyper-V Network Adapter #4
   NetProfile.Name      : ACME.local
   IPv4Address          : 10.0.10.31
   IPv4DefaultGateway   : 10.0.10.1
   DNSServer            : 10.0.1.2
                          10.0.1.3
   
   InterfaceAlias       : Interface used for Switch 1
   InterfaceIndex       : 5
   InterfaceDescription : Microsoft Hyper-V Network Adapter #3
   NetProfile.Name      : ACME.local
   IPv4Address          : 10.0.10.32
   IPv4DefaultGateway   : 10.0.10.1
   DNSServer            : 10.0.1.2
                          10.0.1.3

6. Use the route command to add a persistent route. The mask must be 255.255.255.255 and NOT the same as the interface mask configured earlier because the persistent route to the SQL Server is for its IP Address and not its subnet.

   Copy

   $SQLServerIP = "<SQL Server IP Address>"
   $Gateway = "<Interface used for SQL IPv4DefaultGateway>"
   $InterfaceIndex = "<Interface used for SQL InterfaceIndex>"
   
   route -p add $SQLServerIP `
       mask 255.255.255.255 `
       $Gateway `
       metric 1 `
       if $InterfaceIndex
   

   In our example:

   Copy

   route -p add 10.0.20.20 mask 255.255.255.255 10.0.10.1 metric 1 if 7

   For networks with no routing, such as a lab, the default gateway is 0.0.0.0. Therefore, <Interface used for SQL IPv4DefaultGateway> must be specified as 0.0.0.0. In our example:

   Copy

   route -p add 10.0.20.20 mask 255.255.255.255 0.0.0.0 metric 1 if 7

   If your lab has no routing then you should ensure other means for your 1E Server to connect to the 1E license service via the Internet.

7. Enter the following command to confirm that the <SQL Server IP Address> has a persistent route with the details specified. In our example, this is 10.0.20.20.

   Copy

   route print

8. Enter the following command to verify the route works and uses the correct interface.

   Copy

   pathping ACME-SQL02

   The first line (hop 0) must show the name of the 1E Server and the IP Address of the interface. This IP Address will then be selected as used for SQL in the Switch configuration screen of 1E Server Setup. In our example this would be:

   Copy

   0  ACME-TCN01.ACME.local [10.0.10.31]

Computername

The computername of a 1E Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less. Refer to Computer Names.

DNS Names

Each server that has 1E Platform components installed requires its own DNS Name. A DNS Name can be a DNS alias, CNAME or Host (A) record.

The number of DNS Names used by a system depends on the location of 1E and other Platform services. The table below describes the options.

Where possible the 1E Server DNS Name should be a CNAME Alias which references the (A) Host records for each of the Switch network interfaces registered in DNS.

For multiple Switches to share the same DNS Name, the load balancing options include:

• DNS round-robin: Create a CNAME record which references the (A) Host records for each of the Switch network interfaces registered in DNS.

• Network Load Balance (NLB): Register the 1E Server's DNS Name as the NLB Name, and configure the NLB to forward to each of the Switch IP Addresses.

Service Principal Names

1E Platform and applications use underlying IIS and SQL Server technology, and only require HTTP or MSSQLSvc class SPNs if your company security policy has configured IIS or SQL Server to use Kerberos authentication.

If your IIS server is using Kerberos, then each DNS Name used to access a 1E Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the relevant service account in Directory, which is computer$ by default. This allows 1E web applications to authenticate clients using Windows Authentication where Kerberos is an authentication provider (primary, fallback, or negotiated).

SPNs are not required for DNS Names used to connect to Switches or Background Channel, because they do not use Windows Authentication. However, bear in mind the same DNS Name might be used to access other web applications. If an SPN is not created, then you will see 401 Not authenticated errors in the browser and/or log files.

Service Principal Names (SPN) are attributes of AD accounts. A domain administrator will need to create an HTTP class SPN for the 1E web server service account, by using one of the following methods:

• By editing the ServicePrincipalName attribute of the web server's computer account

• Using the following SETSPN commands, substituting your DNS Name, server and service account

  Copy

  setspn -l ACME\ACME-TCN01$
  setspn -s http/acme-tcn01.acme.local ACME\ACME-TCN01$
  setspn -s http/tachyon.acme.local ACME\ACME-TCN01$

Use each command as follows:

1. List existing SPNs for the service account. Run this to record details before you request for any new SPN(s) to be created. Re-run this after creation, ensuring you wait sufficient time for AD replication to occur.

2. Use this if tachyon.acme.local is a CNAME record and its (A) Host record is acme-tcn01.acme.local.

3. Use this if tachyon.acme.local is a (A) Host record.

The above example assumes:

• The service account for all 1E web application pools is Network Service

• The 1E server name is ACME-TCN01 with a computer account in the ACME domain, which means the service account is ACME\ACME-TCN01$

• The DNS Name for the server is tachyon.acme.local

If in doubt, it does no harm to create an SPN for each DNS Name used to access the 1E Server, including its CNAMEs and (A) Host records using:

setspn -s http/<DNS Name> ACME\ACME-TCN01$

To determine which type of record a DNS Name is, run the following command:

nslookup tachyon.acme.local

• If the command returns Name: acme-tcn01.acme.local and alias tachyon.acme.local then tachyon.acme.local is a CNAME record

• If the command returns Name: tachyon.acme.local and no aliases then tachyon.acme.local is a (A) Host record

More complex scenarios can be configured which requires in-depth knowledge of IIS, SPN and DNS configuration and are beyond the scope of this documentation.

Web Server Certificate

What do I need to begin?

You will need to have requested a Web Server certificate from your Certificate Authority. To get the certificate in your organization you will have either:

• Submitted a CSR and received a password protected .pfx file

• Used the Certificate Enrollment wizard to request a suitable Web Server certificate

Import the Web Server certificate

Once the Web Server certificate has been provided it must be imported into the 1E Server's local computer Personal Certificates store. After importing, you should give the certificate a Friendly Name, so that you can easily identify it for the post-installation task 1E Server post-installation tasks.

1. On the 1E Server, start certlm.msc (or start mmc and add the certificates snap-in for the local machine).

2. Navigate to the Personal Certificates store.

3. Locate the Web Server certificate you have just imported.

4. Right-click on the certificate and select Properties.

5. In the General tab enter a Friendly name, for example, 1E Platform.

6. Click OK to save.

Web Server certificate specification

Each server that has 1E Server components installed requires its own Web Server certificate (except for a remote SQL Server). This certificate is also used by the 1E Switch and the 1E Coordinator. Therefore, a single-server installation requires only one Web Server certificate. This certificate must be provided on the server prior to the installation of 1E.

The Web Server certificate requires the minimum of the following:

1. Issued by a trusted Certificate Authority (CA)

   • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the server

   • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the server

   • The above CA certificates must exist on the 1E Web Server and Windows client devices

   • Most organizations have automated distribution of these CA certificates to servers and clients, using Group Policy for example.

2. Has at least the following Key Usage:

   • Digital signature

   • Key encipherment

3. Has at least the following Enhanced Key Usages:

   • Server Authentication

4. Revocation information is included

   • References at least one CRL Distribution point that uses HTTP - see DMZ Server note below

5. Must have a private key available

The default template Web Server available with a Microsoft PKI is suitable for requesting a 1E Web Server certificate.

Web Server certificates used by 1E Servers must be issued with their fields set as follows.

Examples of old-style certificates.

Fields	Example of old Option 1 type certificate
Subject Common Name Field (subject:commonName)	The DNS Alias FQDN of the server Example: CN=TACHYON.ACME.LOCAL
Subject Alternative Name Extension (extensions:subjectAltName), type dnsName	The DNS Alias FQDN of the server Example: DNS Name=TACHYON.ACME.LOCAL The computername FQDN of the server Example: DNS Name=ACME-TCN01.ACME.LOCAL
Example certificate request	Option 1 type certificates required the CN to be the DNS Alias, and the list of Subject Alternate Names (SAN) to contain the computername FQDN. Also, prior to 1E 5.0 the certificate required its private key to be exportable. 1E 5.0 and later is able to use this type of certificate when upgrading from an earlier version of 1E.

Fields	Example old Option 2 type certificate
Subject Common Name Field (subject:commonName)	The computername FQDN of the server Example: CN=ACME-TCN01.ACME.LOCAL
Subject Alternative Name Extension (extensions:subjectAltName), type dnsName	The DNS Alias FQDN of the server Example: DNS Name=TACHYON.ACME.LOCAL Add any additional DNS Names here.
Example certificate request	Option 2 type certificates required the CN to be the computername FQDN, and the list of Subject Alternate Names (SAN) to contain the DNS Alias. Also, prior to 1E 5.0 the certificate required its private key to be exportable. 1E 5.0 and later is able to use this type of certificate when upgrading from an earlier version of 1E.

Switch certificate files

1E Switches use certificates in the Windows Certificate Store. From version 5.0 onwards they no longer use Switch Certificate files.

Windows Server roles and features

1E Setup will create a website with the necessary bindings, do not pre-create a website of the same name. The following PowerShell commands can be used to install relevant IIS roles and features and record the server configuration in a file.

When you run 1E Server Setup, you may choose to let the Setup perform this operation for you instead of downloading and running the script manually. Just click on Install missing prerequisites after you have run the checks on the Check prerequisites page.

RolesInstall.ps1 - Configure IIS using PowerShell

Import-Module ServerManager

Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-1.txt -Append
Install-WindowsFeature Web-Server,
Web-Http-Redirect,
Web-Dyn-Compression,
Web-Basic-Auth,
Web-IP-Security,
Web-Windows-Auth,
Web-Asp-Net45,
Web-Mgmt-Console,
Net-Framework-45-Core,
Net-Framework-45-ASPNET,
Web-WebSockets
Uninstall-WindowsFeature Web-DAV-Publishing
   
Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-2.txt -Append

When running the above command, if you receive an error that contains The source files could not be downloaded you will need to supply the source path to your Windows Server OS installation media \Sources\sxs folder. Append -source X:\Sources\sxs or -source \\Server\Path\Source\sxs to the command line, adjusted for your drive letter or UNC path.

PowerShell always uses 45 in the names of .NET Framework features, irrespective of the actual version of .NET Framework 4.X installed on the server, like:

• 4.8 in Windows Server 2022 (from 1E 8.1 onwards, any 1E component that requires .NET Framework, requires version 4.8)

• 4.7.2 in Windows Server 2019

• 4.6.2 in Windows Server 2016

Refer to .NET Framework system requirements.

If you prefer to use the Add Roles and Features Wizard to manually enable features then you can use the Display Names listed in the table Windows Server roles and features.

• Web-Http-Redirect is only required to support legacy Content Distribution clients after an in-place upgrade of ActiveEfficiency

• Web-Basic-Auth is only required if you will be installing 1E ITSM Connect or 1E Core for integrating ServiceNow and 1E

ASP.NET Core Hosting Bundle

Required on the 1E Master Stack server if you are installing Content Distribution features.

• If it is not already installed, 1E Server Setup will attempt to automatically download and install version 6.0. However, this supposes your installation account and the server is whitelisted to allow its download.

• You can download and install version 6.0 using a command similar to the following from Download .NET.

  The parameter OPT_NO_X86=1 causes the installer to only install the 64-bit version, which is required by 1E.

  You may experience an error if some bundle components are already installed. If this happens, then re-run using /repair instead of /install.

  Copy

  dotnet-hosting-6.0.x-win.exe OPT_NO_X86=1 /install

You can run the following command to list the installed versions of .NET:

%ProgramFiles%\dotnet\dotnet.exe --list-runtimes

If TLS1.0 is disabled

Web server registry settings

If TLS 1.0 is disabled on the Web server, you must add the following two registry entries, for the 1E Catalog Update Service to successfully connect to the 1E Cloud Catalog.

Import registry entries

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001

SQL BCP

The Export all feature is described in Exporting data from Endpoint Troubleshooting. To enable 1E users with the appropriate permissions to use the Export all feature you must ensure that Microsoft Bulk Copy Program (BCP) is installed on each 1E Response Stack, specifically the Response server where the Core component is hosted.

• If Microsoft SQL Server is installed on the same server as the 1E Response Stack, then BCP will normally be present.

• If the TachyonResponses database is remote to the 1E Response Stack and there is no local copy of Microsoft SQL Server, then you will need to install BCP.

You can confirm BCP is installed by starting a command prompt and typing bcp and usage information is displayed. The command bcp -v displays the version.

Install the following components to get BCP working:

To verify the components have been installed, you can use AppWiz.cpl and check for the Product Name.

Services and NTFS Security

1E and SLA Platform services, including web application pools, use built-in accounts Local System (SYSTEM) and Network Service (NETWORK SERVICE) by default, and 1E recommends this configuration. You must ensure these built-in accounts have the necessary NTFS security permissions on the 1E and SLA Platform installation and log folders.

If you are using default installation settings for the 1E server on a default configuration of Windows Server, then Local System has the necessary permissions by default, but Network Service requires some additional steps. The simplest method is to add Network Service to the Administrators localgroup, which allows the default installation and logs folders to be created during installation.

However, adding Network Service to the Administrators localgroup is not considered best practice, therefore alternative methods are described below.

The table below lists the 1E services and their default service accounts.

The table below lists the default folder locations which must have NTFS security permissions configured for all service accounts. The 1E installation process does not modify permissions, except for the %ProgramData%\1E\Licensing\ folder which does receive full permissions for Network Service.

For a default installation of 1E on a default configuration of Windows Server, Local System (SYSTEM) has the necessary permissions by default, but Network Service requires some additional steps.

You have a choice of how to configure NTFS security for Network Service, using one of the following options, according to your organization's policies. You can pre-create the 1E installation and logs folders prior to installation and apply NTFS permissions on these instead of their parent folders.

Using a non-default location for the Installation Folder

If you are installing in a non-default installation folder, or the default installation folder has non-standard NTFS security, then before installation, you must ensure the installation folder is pre-created with suitable NTFS security applied. If this is not done, some services will fail to start, or users will not be able to access the website. The NTFS security for the service accounts described above must be explicitly applied.

In addition, the Users or Authenticated Users localgroup must have a minimum of read & execute permission on each of the Web application folders folder, subfolders and files. This is simplest to achieve by granting permission on the INSTALLDIR folder.

The example screenshot shows:

• A non-default installation INSTALLDIR=D:\Program Files\1E\Tachyon\

• RX permissions for the Users group is applied to the 1E folder

• Other permissions are inherited from the root of the D: drive

• INSTALLDIR permissions are inherited from the 1E folder

• NETWORK SERVICE is a member of the Users localgroup

  

Using a non-default location for the Logs Folder

The accounts used by 1E services and application pools must have a minimum of Full Control permission on the logs folder (folder, subfolders and files. The example screenshot shows a default installation. For a default installation, the only permissions necessary are SYSTEM and Administrators, both Full Control.

1E Platform databases can be installed on one or more SQL Server database instances. These SQL Server instances can be on the 1E application server (local) or remote. You can allow the 1E Server Setup to create the databases in their default locations, or you can pre-create them with appropriate permissions before installation if you want to select the location and sizes of the databases. For a new installation, and for upgrades, the Installation Accounts requires a SQL Login with appropriate permissions. Refer to High Availability options for SQL Server.

1E Platform supports the following High Availability (HA) options for SQL Server:

• AlwaysOn Availability Group (AG) using an AG Listener

• Failover Cluster Instance (FCI)

The following is a list of databases used by 1E Platform. In the Database servers screen, you can select the name of the SQL Server instance, but it does not let you change the database names.

• 1ECatalog

• SLA databases must be installed on the same instance:

  • SLA-Data

  • SLA-Shared

  • SLA-Integrate

• ContentDistribution (required for Content Distribution)

• SLA-BI (this is the Business Intelligence database required for Patch Success)

• TachyonMaster

• TachyonResponses (required for a Response Stack)

• TachyonExperience (required for Experience)

The following is a list of database cubes used by 1E Platform.

• SLA-BI (this is the Business Intelligence cube required for Patch Success)

Default configuration of databases

If you allow the installer to create new databases, they each have the following default settings. Databases will grow automatically to the sizes estimated in Server sizing requirements.

If the model system database has been changed to have a larger size than the values specified in the table above, then the 1E Server installer may report an error executing Bootstrap.sql on MasterDatabase. Rebooting the SQL Server may cure the error.

Creating your own databases

You may be required to create databases by hand before installation. This is also known as pre-creating databases. Below are some of the reasons why your SQL administrator may require you to do this:

• 1E Server Installation Account is only allowed rights on existing databases and not allowed rights to create them.

• Locations of the database files need to be different from the defaults used on the SQL Server instance(s).

• The initial size of the database files needs to be set to their estimated full size given in Server sizing requirements.

SQL Login for the server installation account

The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions required by the installation account depends on which 1E components it is installing.

Master Stacks

For master stacks sysadmin is required as follows to:

• Install 1E Catalog.

• Create Linked Servers for SLA, which requires sysadmin for the SQL database instances for both SLA and 1E Catalog databases.

• Create Linked Servers for BI, which requires sysadmin for the SQL database instances for both SLA and BI databases, and the SSAS instance for the BI cube (required only by Patch Success).

Response Stacks

Example SQL scripts for creating a SQL Login and granting roles

The following examples assume ACME\TCNinstaller01 is the 1E Server Installation Account.

When the account is not permitted to have the sysadmin SQL Server role, then a sysadmin can use the following script to create a SQL Login and grant it rights.

USE [master]
GO
CREATE LOGIN [ACME\TCNinstaller01] FROM WINDOWS
GO
GRANT ALTER ANY LOGIN TO [ACME\TCNinstaller01]
GO

If the 1E Server Installation Account is permitted to create the databases, then a sysadmin can use the following script to add the SQL Login to the dbcreator role.

Grant dbcreator:

USE [master]
GO
ALTER SERVER ROLE [dbcreator] ADD MEMBER [ACME\TCNinstaller01]
GO

If the databases have been pre-created, then a sysadmin can use the following script to add the SQL Login to the db_owner role on each pre-created database.

Grant db_owner:

USE [TachyonMaster]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO
USE [TachyonResponses]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO

After the databases have been created, best practice is to change the owner of each database to sa, to avoid issues if the owner's Windows account is deleted in future.

The following script can be used to change the owner of each 1E database to sa. This will work even if the sa login has been disabled, which is also best practice.

ALTER AUTHORIZATION ON DATABASE::TachyonMaster To "sa"
GO
ALTER AUTHORIZATION ON DATABASE::TachyonResponses To "sa"
GO

SQL Login for the 1E service account

The SQL Login that is used by the 1E Server web applications and services depends on whether the SQL Server is remote from the 1E Server or is local, as described in the following table:

Before upgrading 1E, or installing or upgrading Consumer applications like Application Migration or AppClarity, the SQL Login must be granted the following rights to support Database Snapshot of the 1E Catalog and SLA databases, to restore them if an error occurs:

• dbcreator rights on the SQL database instance hosting the 1E Catalog database.

• dbcreator rights on the SQL database instance hosting the SLA databases.

During installation, the 1E Server Setup will always:

• Attempt to create the SQL Login.

• Grant it db_owner permission on each of the 1E databases.

• Remove the db_owner permissions when installation is completed.

Keeping databases during re-installation and upgrade

If re-installing or upgrading 1E, you need to decide if you will keep the existing databases or create new ones. Before doing a re-installation or upgrade of the 1E Platform, make a backup of the following (but first see the note below about automatic backups):

• 1E Master database

  Backing up the 1E Responses database is not usually needed, unless there are instruction responses that you need to keep. 1E responses are not permanently held data and will naturally expire according to the settings specified when an instruction was run, typically in hours or possibly days. If in doubt, there is no harm in backing up the 1E Responses database as well.

• 1E Server installation directory

  • Including the config files, which may have been manually updated in the previous installation

  • Switch certificate files

• Earlier versions of Product Packs that have been modified

1E Setup will automatically perform a backup of the following items:

• 1E Server installation directory. This is backed up to a subfolder named Tachyon.bak under the root installation folder for 1E . All files, including the .config files and certificate files, will be copied.

• IIS configuration. This is done by taking a copy of the applicationhost.config file from the Windows system folders. The backup file is placed at the same location and is named like the original file with a suffix that indicates the date and time when the copy was taken.

• The following databases are backed up to the default location for backups that is configured in the database server. By default, this points to a subfolder named Backups under the folder where the executable for SQL Server is installed. Unless you are installing a small lab or proof-of-concept, this is usually not a good location for the backups, so make sure that you configure the backup location in SQL Server to an adequate folder before starting the 1E upgrade:

  • 1ECatalog

  • ContentDistribution (optional, required by Content Distribution)

  • SLA-Data

  • SLA-Shared

  • SLA-Integrate

  • TachyonMaster

  • TachyonResponses

  • TachyonExperience (optional, required for Experience Analytics )

The Product packs are not copied by themselves, but they are kept in a table within the TachyonMaster database, which is backed up.

1E users and approvers require AD accounts with email addresses to support approval workflow and notifications.

Mail Server

For details about mail server requirements, refer to SMTP server.

A reference to create and configure the Microsoft Entra ID applications required for on-premises 1E 9.x

AAD - 1E Client Assertion

Certificate requirements

You will need three certificates will, although the third certificate is only required if you are using features that use non-interactive logins.

• 1E Platform Token: Used to sign requests between 1E components. All 1E servers must share the same certificate. This means the certificate needs to be created with its private key exportable, and then imported on each server.

• 1E Client Assertion: Used by the platform server to sign authentication requests to your IdP, and Directory Searches. The public key of this certificate must be exported (for example as a Base-64 encoded X.509 CER file, without private key) and uploaded to the IdP client assertion application configured for Directory Searches discussed later.

• 1E Integrations: Only required if you integrate any external applications such as ServiceNow, the 1E Authentication Proxy (Feature deprecated in 1E Platform v9.1), unattended scripts, integration by Shopping or NightWatchman Enterprise. The public key of the certificate must be exported (for example as a Base-64 encoded X.509 CER file, without private key).

You can leave out the 1E Integrations certificate if you do not intend to integrate any external applications.

This page outlines how to create the certificates needed to configure AAD applications for your on-premises installation of 1E. For full documentation on 1E certificate requirements refer to Certificate requirements.

Create required certificates

The certificates you create have no specific requirements other than they must be CNG. These certificates can also be issued by a PKI if you prefer, they do not have to be self-signed. Unlike certificates used for web servers, where there is a requirement there is a trust chain to a root CA certificate, CNG certificates can be self-signed. This is because the trust relationship is defined either between:

• Platform components

• A platform service and the identity provider

• Integration features and the identity provider

Both parties in each relationship have local access to their certificate and can prove their identities using standard cryptography sign/verify procedures.

1. On a server other than a 1E server, from an Admin PowerShell prompt create the three required certificates. Only the first two are needed for on-premise v9.0 of 1E Platform.

   Copy

   New-SelfSignedCertificate `
       -Subject "CN=1EPlatformToken" `
       -CertStoreLocation "Cert:\LocalMachine\My\" `
       -KeyAlgorithm "RSA" `
       -KeyLength 2048 `
       -Provider "Microsoft Software Key Storage Provider" `
       -KeyExportPolicy Exportable
   

    

   Copy

   New-SelfSignedCertificate `
       -Subject "CN=1EClientAssertion" `
       -CertStoreLocation "Cert:\LocalMachine\My\" `
       -KeyAlgorithm "RSA" `
       -KeyLength 2048 `
       -Provider "Microsoft Software Key Storage Provider" `
       -KeyExportPolicy Exportable
   

    

   Copy

   New-SelfSignedCertificate `
       -Subject "CN=1EIntegration" `
       -CertStoreLocation "Cert:\LocalMachine\My\" `
       -KeyAlgorithm "RSA" `
       -KeyLength 2048 `
       -Provider "Microsoft Software Key Storage Provider" `
       -KeyExportPolicy Exportable

   

   The three certificates will be in the local computer certificate store:

2. Export all three certificates as individual .pfx files ensuring you select Yes, export the private key.

   

3. Once all three certificates have been exported the certificates can be deleted from the local computer certificate store.

4. Copy the three .pfx files to the 1E server.

   

5. Import each certificate into the local computer certificate store on the 1E server making sure not to enable the Mark this key as exportable option.

   

6. Export all three certificates again but this time as a Base-64 encoded X.509 CER file, without private key.

   

Setting up the Client Assertion

This Client Assertion Application is used by 1E to perform directory searches in your IdP. This allows a 1E Administrator to add users to the platform and give them assignments for roles and management groups.

1. In the Azure admin portal navigate to Microsoft Entra ID > App registrations > New registration.

   

2. On the Register an application screen, enter 1E Client Assertion as the name, then click Register.

   Although there are no strict requirements on the actual name, the application will be used by 1E for client assertion. All the other settings on the page can be left at their default values.

   

3. Select Certificates & secrets.

   

4. Select the Certificates tab, click Upload certificate.

   Upload the Signing certificate for IdP requests CER file you exported in Request-signing certificates.

   

5. Select the .cer file for the Client Assertion certificate and click Open.

   

6. Enter a description and click Add.

   

7. Once the certificate is added, click API Permissions.

   

8. Select Microsoft Graph and then Application permissions on the resulting popup.

   

9. Scroll down the list of permissions, expand GroupMember and add the following permissions.

   GroupMember.Read.All

   User.Read.All

   If these application permissions are not applied, you will not be able to add users to the 1E Platform. The Client assertion uses app permissions, there is no user as the authentication flow uses a certificate.

   

   The application also needs the following Delegated permissions User.Read. This permission is granted by default and does not need to be changed.

10. Click on Grant admin consent for….

    

11. Confirm you wish to grant consent, you should see something similar to the following, with a green check next to the application entries.

    

AAD - 1E PKCE

This application is used to read the credentials for each account that logs into the 1E portal.

1. In the Azure admin portal navigate to Microsoft Entra ID > App registrations > New registration.

   

2. Type in the name 1E PKCE, although there are no strict requirements on the actual name, the application will be used by 1E to validate the user that is logging in.

   • In the Redirect URI (optional) field type in your URI value.

   • Make sure it is set to Single-page application (SPA) and enter the URI in this format:

     https://Your-companyFQDN>/Portal/api/Authentication/IdentityProviderRedirect then click Register.

     

     The Redirect field is case-sensitive.

3. Select Authentication.

   

4. This application needs to have Allow public client flows set to disabled. Scroll down to the bottom, make sure the slider is set to No and click Save.

   

5. Select API permissions.

   This application needs Microsoft Graph delegated API permissions of User.Read. This permission is granted by default and does not need changing. Click on Grant admin consent for….

   

   If these application permissions are not applied for the 1E PKCE app users will not be able to log in to the system. The 1E PKCE app uses delegated permissions as the User.Read.All permission relates to the user logging on.

6. Select Yes in the Grant admin consent confirmation popup.

   

7. To confirm admin consent has been granted, look for a green check in the Status column.

   

AAD - 1E Integrations

The 1E Integration app is optional and only required when using non-interactive logons, however you will need to create it if you want to integrate things like:

• 1E Authentication Proxy (This feature is deprecated from 1E platform v9.1)

• 1E Shopping

• 1E NightWatchman Enterprise

• External applications like ServiceNow integration

• Unattended scripts

1. Select App registrations and choose New Registration.

   

2. Enter 1E Integrations for the name, then click Register.

   

   In the Overview menu make a note of the Application (client) ID, you will need to send this to your 1E Account Team as part of the overall provisioning process.

3. Select Certificates & secrets.

   

4. Select the Certificates tab and then click upload certificate.

   

5. Select the .cer file for the 1E Integrations certificate and click Open.

   

6. Enter a description and click Add.

   

7. You will then see a thumbprint of the certificate.

   

Gathering the AAD information needed

Once you have configured your applications, you will need to capture the following information for use on the Identity Provider screen in 1E Server Setup.

• Tenant Metadata: This can be copied from Microsoft Entra ID > App registrations then selecting Endpoints.

  

• On the displayed panel on the right hand side of the screen, copy the value for OpenID Connect metadata document.

  

• Tenant ID: This can be copied from the Microsoft Entra ID Overview page.

  

• Application (client) ID: For your applications, you can copy these from the Overview menu of each application.

  

Information needed during installation

Use the following table to help you complete the Identity Provider section of the 1E Platform setup installer.

Identity Provider installer screen:

Okta - 1E Client Assertion

The Client Assertion Application will be used to perform directory searches in 1E. This will allow a 1E Administrator to add users to the platform and give them assignments for roles and management groups. These instructions show how to register the Client Assertion Application in Okta.

1. In the Okta admin portal navigate to Applications and select Create App Integration.

   

2. Once that opens select API Services and then click Next.

   

3. In the New API Services App Integration section, fill in the App integration name field. We suggest you name this 1E Client Assertion and then click on Save.

   

4. In the Client Credentials section, under Client authentication, select Public key/Private key, and in the PUBLIC KEYS section select the Save keys in Okta option.

   

5. Select Add key, in the black field displayed paste the entire certificate file that you created in Certificate requirements, and then click Done.

   For Okta this needs to be presented in JSON Web Key (JWK) format.

   

6. In General Settings the Require Demonstrating Proof of possession (DPoP) header in token requests option is selected by default. You must deselect this option, as DPoP is not currently supported by 1E for authentication.

   Click Edit, deselect Require Demonstrating Proof of possession (DPoP) header in token requests and then click Save.

   

Okta - 1E PKCE

This application will be used to read the credentials for each account that logs into the 1E portal. These instructions show how to register the PKCE Application.

1. In the Okta admin portal, navigate to Applications and select Create App Integration.

   

2. In the new screen displayed, select OIDC - OpenID Connect in Sign-in method, and select Single-Page Application in Application type, then click Next.

   

3. In the App integration name field set the name for the application, we recommend calling this 1E PKCE.

   1. In Grant type, check the Authorization Code and Refresh Token checkboxes.

   2. In Sign-in redirect URIs input your URI value into the field.

      For example, the URI will be in the form of https://<TachyonFQDN>/Tachyon/api/Authentication/IdentityProviderRedirect

      The Redirect field is case-sensitive.

      

   3. Choose Skip group assignment for now in Controlled access.

      

      Click on Save.

Okta assign permissions to the applications

When the applications have been created you then need to grant the following permissions.

1. Navigate to the 1E PKCE Application and click on Okta API Scopes.

   

2. Grant okta.users.read. Click on Grant for this permission, you will see Granted in the Consent column.

   

3. Perform the same steps to add the following permissions for the 1E Client Assertion Application.

   okta.groups.read

   okta.users.read

   

Okta assign users to the applications

To use the applications and allow users to be added to 1E you also need to first assign those users to the applications you just created in Okta. We recommend that you create a group for this purpose and add the group to the applications. That way user assignment can be via the group.

1. Navigate to the Applications and click on Assign Users to App.

   

2. Select each application and assign the group you want to use.

3. Subsequently you will only need to modify the group membership to assign or remove users from the applications.

Okta - 1E Integrations

This Client Assertion Application is used for non-interactive logins.

1. You will need to get a certificate from your Certificate Authority to use for your non-interactive logins, for Okta this needs to be presented in JSON Web Key (JWK) format.

   To get the certificate in this format you can use the 1E Toolkit from the TeamViewer DEX Support Portal.

   On the device where the certificate is installed, run PowerShell as an administrator. Then navigate to the 1E PowerShell toolkit directory and run the following cmdlet, replacing <subjectname> with the name of your certificate.

   Copy

   Import-Module 'C:\Program Files\1E\PSToolkit\ps1etoolkit.psd1'
   
   Get-1EJwkFromCertificate -certsubject CN=<subjectname> 

2. In the Okta admin portal navigate to Applications and select Create App Integration.

   

3. Once that opens, select API Services and then click Next.

   

4. In the New API Services App Integration section, fill in the App integration name field. We suggest you name this 1E PKCE Non-Interactive and then click Save.

   

5. In the Client Credentials section, under Client authentication, select Public key/Private key, and in the PUBLIC KEYS section select the Save keys in Okta option. Take a note of the Client ID, you will need to send this to your 1E Account Team as part of the overall provisioning process.

   

6. Select Add key, in the black field displayed paste the JWK file you obtained in step 1 and then click Done.

   

7. The new Okta application will need the following permissions:

   

Gathering the Okta information

Once you have your applications configured, you will need to capture the following information to be used on the Identity Provider screen in 1E Server Setup.

• Tenant Metadata: This can be found by navigating to the metadata endpoint. The URL has the form:

  https://<okta instance URL>/.well-known/openid-configuration

  Selecting this displays the Okta OpenID MetaData:

• Tenant ID: This can be found at the top-right of the Okta portal:

  

• Application (client) ID: For both of your provisioning applications. These can be copied from the General tab of each application:

  • 1E Client Assertion: Directory Search

  • 1E PKCE: PKCE Grant Flow App for Interactive Logins

  • 1E Client Assertion Non-Interactive: Client Grant Flow App for Non-Interactive Logins

• An Okta user account that will be used as the Setup user during this installation of 1E

This article describes how to configure Windows Active Directory as an Identity Provider in 1E Platform.

Prerequisites

• A certificate that will be used by the 1E Platform to sign platform tokens. This certificate must be a CNG-compliant certificate, be present in the local certificate store, and have an accessible private key.

• If you want to use JSON Web Tokens (JWTs) for non-interactive authentication, use any suitable certificates (5).

Configuration

To set up Windows AD as an identity provider, you will need to change your tenant configuration. You can do this when you install 1E 9.1 or directly in the tenantconfig.json.

1E Server Setup v9.1

The following settings are mandatory:

• A certificate for platform tokens. You can select this using the […] button (4), the certificate's thumbprint will then be visible in the text box (3).

• Click Add permissions for private key for the certificate (5).

• Specify a user that will be added as a Principal and granted permissions for your initial configuration (1). You can optionally promote that user to Full Administrator (2).

You can also specify addresses of any GC or LDAP server(s) you wish to use (6). By default, Setup will choose GC:// but you can use a different value. multiple GC and LDAP servers can be added if separated by a semicolon.

Available settings in tenantconfig.json

While you are not required to make any changes to tenantconfig.json after the installation, any settings entered in 1E Setup, along with other settings that are created for you, can be viewed and amended using tenantconfig.json located at %PROGRAMDATA%\1E\Tachyon\.

Tenantconfig.json settings:

The following is an excerpt from an example tenantconfig.json

"AuthenticationConfiguration": [
    {
        "IdPType": "Windows",
        "MaximumSessionRefresh": 4,
        "MaximumSessionTimeSeconds": 3600,
        "Configuration": {
            "AppId": "1E1E1E1E-1E1E-1E1E-1E1E-1E1E1E1E1E1E",
            "MetadataEndpoint": "http://your.server.com/tachyon/api/NonStandardIdPProxy/Metadata",
            "DirectoryAppId": "1E1E1E1E-1E1E-1E1E-1E1E-1E1E1E1E1E1E",
            "ClientAssertionAppId": "1E1E1E1E-1E1E-1E1E-1E1E-1E1E1E1E1E1E"
        }
    }
]

Setting up non-interactive authentication (JWT)

Authentication using JWTs requires some extra steps before you can use it and are in addition to the usual Kid to UPN mappings you would have with any other identity provider.

You need to do this because 1E Platform wraps Active Directory in an OAuth layer, and we need to cryptographically verify any JWTs an external system would use. With a web-based IdP like Azure or Okta the IdP performs the verification. Because Active Directory does not posses that ability, the 1E Platform must do it.

You can store certificates either in the local certificate store on the server where 1E Platform is running, or you can upload them directly into the platform. You can do this using either 1E Powershell Toolkit or by directly accessing the APIs.

Using the PowerShell Toolkit

The following cmdlets have been added to the toolkit to support non-interactive authentication.

You can download the toolkit from the TeamViewer DEX Support Portal.

Using the API

The platform requires a directory service for identity and authentication. This can be:

• Active Directory (on-premises), or

• Azure Active Directory Domain Services (Azure ADDS)

Azure-Based Deployment (Azure ADDS) – 9.x

1E Platform 9.x can be deployed on Azure virtual machines using Azure Active Directory Domain Services (Azure ADDS) as the identity provider.

In this deployment model:

• Servers may be hosted on Azure VMs

• Servers are joined to Azure ADDS instead of a traditional on-premises domain

• Components communicate over the network without requiring traditional domain-joined infrastructure

Prerequisites

• Azure ADDS must be configured

• A domain administrator account must be available

• All VMs must be joined to Azure ADDS

• All VMs must be able to communicate over the network

Network Requirements

Ensure the following ports are allowed (inbound and outbound):

• TCP 443

• TCP 4000

• TCP 1433

ICMP should be allowed for connectivity testing.

For Azure deployments, ensure these ports are open in Network Security Groups (NSGs).

Certificates and DNS

• The DEX Response server must use a public DNS name for WAN connectivity

• This DNS name must be included in the certificate Subject Alternative Name (SAN)

Client Requirements

• Clients must have a valid certificate installed

• Clients must be configured with the public URLs for switch and background services

Installation Accounts

1E Server Installation Account

The server installation account has the following requirements on the server.

• Local admin rights on the 1E Server: It must be an Active Directory domain user account that is a direct or indirect member of the Administrators local group on the server where 1E Server will be installed.

• It can be disabled (not deleted) in Active Directory after additional 1E admin users have been created in 1E , and installation has been verified.

• The server installation account requires SQL rights, refer to SQL Databases

1E client Windows Installation Account

The 1E Client installer installs a service as local system, therefore the installation account for Windows clients must be capable of being elevated in order to run the installer. The simplest way of achieving this is for the account to have full local administrator rights (as a member of the localgroup administrators, either directly or indirectly).

1E client Non-Windows Installation Account

To install the 1E Client on a non-Windows client the installation account must have privileges to run the sudo command.

1E Users Accounts

Each 1E user requires an account in the Identity Provider used. All accounts must have their userPrincipalName (UPN) attribute populated, which is normal, but may be missing if users accounts have been created using scripts.

1E users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.

Groups that are setup in the Identity Provider are recommended for role-based access control (RBAC) within 1E but are not mandatory. Groups can be assigned to 1E roles after installation, they are not required during installation. They are added as 1E groups and configured in the same way as user accounts. A 1E user can therefore be a user account or in a group within the Identity Provider. Groups are not mandatory because users can be assigned to roles and managed within 1E instead of the Identity Provider, or a combination.

1E Server Setup assigns a limited set of permissions to the Setup user account (specified during installation/updates), which cannot be edited, refer to Roles page. It is possible to increase this user account to have Full Administrator access during installation/upgrade, 1E recommend that this user account is viewed as a service account and kept with the minimum permission.

A group is also useful to configure access to the CatalogWeb Admin page, refer to Rebuilding the Catalog.

Service accounts

1E Platform uses either Network Service or Local system for all its services and web application pools. Refer to the following sections regarding any rights these accounts may require:

• Service Principal Names

• Services and NTFS Security

• SQL Login for the server installation account

• SQL Login for the 1E service account

• Microsoft Endpoint Configuration Manager preparation

1E Platform requires permission to access various features of Configuration Manager when you implement any of the following optional features:

• Content Distribution

• System Center Configuration Manager connector

Configuring SQL rights in the Configuration Manager database

The Network Service account of the 1E Master Stack server requires a SQL Login, with all the following rights in the Configuration Manager site database.

• db_datareader database role

• Explicit Execute permissions to the scalar value function fn_GetAppState

• Explicit Execute permissions to the scalar value function fnGetSiteNumber

Using Windows Authentication

If the connector is using Windows Authentication, then you can use one of the following:

1. Create a SQL Login for the 1E server's computer$ account, and explicitly grant it the above rights.

2. Add the 1E server's computer$ account to the ConfigMgr_DViewAccess localgroup on the Configuration Manager database server, this is the preferred method.

You may already be familiar with configuring ConfigMgr_DViewAccess if you have previously set up Configuration Manager access for older versions of Content Distribution Dashboard which used ActiveEfficiency Server, or the ActiveEfficiency Scout, as used for AppClarity 5.x or Shopping 5.x and 6.0

The existence of the ConfigMgr_DViewAccess localgroup depends on the version of Configuration Manager. It should exist for a Primary Site, but may not exist for a CAS. If it does not already exist, it is safe for you to manually create the localgroup on the SQL Server used by the Configuration Manager database. If it already exists, you will need to confirm it has a SQL Login and all the necessary rights, as the Configuration Manager setup does not always configure this group correctly.

The following SQL script can be used to create a SQL Login for ConfigMgr_DViewAccess and grant it permissions on the Configuration Manager database. Before you run the SQL script, you must first:

1. Manually create the localgroup on the SQL Server

2. Add the Tachyon server's computer$ account to the localgroup

ConfigMgr_DViewAccess_permissions.SQL

Copy

-- Connect to the SQL instance using an account that has sysadmin rights.
-- Execute this SQL script on the Configuration Manager database.
-- The script creates a SQL Login on the instance for [hostname\ConfigMgr_DViewAccess]
-- and grants it the following rights on the Configuration Manager database:
-- [db_datareader]
-- EXECUTE on [dbo].[fn_GetAppState]
-- EXECUTE on [dbo].[fnGetSiteNumber]
 
DECLARE @SqlLogin nvarchar(2000)
DECLARE @SqlString nvarchar(max)
 
SET @SqlLogin = CAST(host_name() AS varchar(512)) + '\ConfigMgr_DViewAccess'
PRINT 'Granting permissions for ''' + @SqlLogin + ''' on database ' + DB_NAME() + ' ...'
 
SET @SqlString = '
IF NOT EXISTS ( SELECT schema_name FROM information_schema.schemata WHERE schema_name = '''+@SqlLogin +''' )
EXEC (''CREATE SCHEMA [' + @SqlLogin + ']'')
'
EXEC sp_executesql @SqlString
 
SET @SqlString = '
IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = '''+ @SqlLogin +''')
CREATE LOGIN [' + @SqlLogin + '] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
'
EXEC sp_executesql @SqlString
 
SET @SqlString = '
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = '''+ @SqlLogin +''')
CREATE USER [' + @SqlLogin + '] FOR LOGIN [' + @SqlLogin + '] WITH DEFAULT_SCHEMA=[' + @SqlLogin + ']
'
EXEC sp_executesql @SqlString
PRINT 'SQL Login created.'
 
SET @SqlString = '
ALTER ROLE [db_datareader] ADD MEMBER [' + @SqlLogin + ']
GRANT EXECUTE ON [dbo].[fn_GetAppState] TO [' + @SqlLogin + '] AS [dbo]
GRANT EXECUTE ON [dbo].[fnGetSiteNumber] TO [' + @SqlLogin + '] AS [dbo]
'
EXEC sp_executesql @SqlString
PRINT 'Permissions granted.'

When you run 1E Server Setup, the Content Distribution screen will attempt to validate the existence of the ConfigMgr_DViewAccess localgroup and membership of the Content Distribution server's computer$ account. The validation test will fail if the installation account does not have sysadmin rights on the SQL Server instance used by Configuration Manager. This is not a fatal error as long as you are sure the computer$ account is a member of the ConfigMgr_DViewAccess localgroup.

Using a specific SQL login:

If you opt to use a connector using a specific SQL Login, then create the login on the Configuration Manager database and grant it the above rights.

To install Content Distribution features, 1E Server Setup requires your server installation account to have the following rights. Refer to 1E Server setup.

• Read-only Analyst rights in Configuration Manager Console - so that Setup can query the Site Server for details of the Configuration Manager database.

• SQL Login (with public role) on the SQL database instance that hosts the Configuration Manager database - so that Setup can run a SQL query to validate that the machine account is a member of the ConfigMgr_DViewAccess localgroup on the SQL Server.

Configuring Site Settings in Configuration Manager

You must enable certain Configuration Manager site settings if you plan to use the System Center Configuration Manager connector to populate Inventory.

The following Client Settings must be configured to gather inventory and usage data from clients, and applied to relevant Collections containing in-scope devices:

• Software metering (metering rules are not necessary)

• Software inventory

• Hardware inventory

The following Discovery Methods must be configured to gather Active Directory data about clients, and applied to relevant Domains and OUs containing in-scope devices:

• Active Directory System Group Discovery (default attributes are sufficient)

Ensure devices that will be used to validate and test the 1E installation has the following:

• Be a supported device platform, refer to 1E Client requirements

• Have appropriate scripting support, refer to Scripting requirements.

• Have a computer certificate, refer to 1E Client certificate requirements

1E integration with Content Distribution on Windows devices

Configuration Manager present

You do not need to make any configuration changes to Content Distribution for it to integrate with 1E. Refer to Introducing Content Distribution

Configuration Manager not present

You can deploy Content Distribution to Windows devices where the Configuration Manager client is not present. You will need to enable the following bits in relevant installer properties:

• CompatibilityFlags bit 1 enable long hashes

• SpecialNetShare bit 13 enable HTTP(S)

These are enabled by default in the Content Distribution client module of the 1E Client.

1E Client certificate requirements

If you have configured 1E Server to require client certificates then each device requires a certificate with the following properties, so the client can be authenticated by the 1E Switch. Refer to Client certificates.

1. Issued by a trusted Certificate Authority (CA).

   • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the client.

   • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the client.

   • If either of these CA certificates is different from those used by the 1E Web Server, they will need to be exported and imported on the 1E Web Server.

   • Most organizations have automated distribution of these CA certificates to clients and servers, using Group Policy for example.

2. Has at least the following Enhanced Key Usage.

   • Client Authentication

3. Has at least the following Key Usage.

   • Digital Signature

   • Key encipherment

4. Has a private key.

   • For workgroup and non-Windows devices, the private key must be exportable

5. Revocation information is included.

   • References at least one CRL Distribution point that uses HTTP

6. Has a Subject Name of type Common Name CN=<computername> or Subject Alternative Name DNS Name=<computername> where <computername> depends on the type of device:

   • On domain-joined Windows PCs this must be the computername FQDN of the computer, for example W701.ACME.LOCAL.

   • On workgroup Windows PCs and non-Windows devices, this must be the computername of the computer - as returned by the hostname command, for example on Windows PC this could be W701, and on a Mac this could be MAC01.local.

In organizations that have an established PKI, the client devices will probably have a suitable certificate already, along with relevant Trusted Root CA certificates.

For non-Windows devices, the certificate files must be included in the 1E Client installation folder structure, as described below in Configuring the Non-Windows 1E certificate using OpenSSL.

Certificate Authority (CA) public keys

1E clients need to authenticate Switches and Switches need to authenticate 1E clients. In each case, one end of a secure connection requires the public key for each CA in the other end's certificate certification path (trust chain).

The 1E client needs the public key of each CA in the Switch's certification path. These public keys are stored differently on the client device depending on the type of OS.

• For Windows devices, CA public keys are normally stored in the Windows Trusted Root Certification Authorities store.

• For non-Windows devices, CA public keys are stored in a cacert.pem located in the 1E Client installation folder.

• For macOS devices, you have a choice of storing CA public keys in the macOS KeyStore or using the cacert.pem file approach required by other non-Windows devices.

The following points should be noted for Windows devices:

• If each client device has an identical certification path as the Switch, then its CA certificates (public keys) will probably already exist in the Windows Trusted Root Certification Authorities store. This is a typical situation in a small-scale lab with a simple PKI.

• If any client device has a different certification path then the certificates (public keys) of the different CAs will need to be added to the corresponding certificate store on Windows devices, either Trusted Root Certification Authorities or Intermediate Certification Authorities.

• In each of the above cases, the CA certificates (public keys) may have been deployed by Group Policy.

Configuring the Non-Windows 1E certificate using OpenSSL

Each non-Windows device requires its own certificate. Below is a guide for using a Microsoft CA to issue a certificate (which is the same for Windows computers), then exporting it and using OpenSSL to prepare it before installing it on a non-Windows device.

First, you will need to have created a new Certificate template on your Certificate Authority by making a duplicate of either the Computer or Workstation template and configuring it with at least the following properties:

• General: Use a suitable name such as 1E Devices and validity period.

• Request Handling: Allow private keys to be exported.

• Subject Name: Allow information to be supplied in the certificate request, rather than being built from Active Directory information.

• Extensions: Application Policies should contain only Client Authentication.

• Security: Ensure relevant users and computers will be able to request certificates.

Once the new template is created on the CA, issue it.

Using the issued template, request a certificate for a target device, export it in .pfx form and remember the password.

The target device requires a copy of the basic cacert.pem and the .pfx file with its password removed. You can do this using the following steps. Use the relevant OpenSSL version for the OS. OpenSSL is normally available by default on Linux and Mac devices. If you want to follow these steps on Windows, you will need to download the open-source version appropriate to your OS.

1. First, extract the certificate.

   Copy

   openssl pkcs12 -clcerts -nokeys -in <YourPKCSFile>.pfx -out certificate.crt

2. Second, the CA key.

   Copy

   openssl pkcs12 -cacerts -nokeys -in <YourPKCSFile>.pfx -out ca-cert.ca

3. Now, the private key.

   Copy

   openssl pkcs12 -nocerts -in <YourPKCSFile>.pfx -out private.key -passout pass:TemporaryPassword

4. Remove the passphrase.

   Copy

   openssl rsa -in private.key -out new.key -passin pass:TemporaryPassword

5. Put things together for the new PKCS-File on Windows, type can be used instead of cat.

   Copy

   cat new.key > PEM.pem
   cat certificate.crt >> PEM.pem
   cat ca-cert.ca >> PEM.pem

6. And create the new .pfx file, when prompted for a password ensure that you enter an empty password, that is press enter when prompted for the password and confirmation without entering any text.

   Copy

   openssl pkcs12 -export -nodes -CAfile ca-cert.ca -in PEM.pem -out Tachyon.pfx

Now you have a new PKCS12 key file without a passphrase on the private key part. This Tachyon.pfx file and the cacert.pem file, must be placed in one of the following locations - depending on the OS. These are hidden folders.

On Linux and Solaris:

/etc/1E/Client/.sslcerts

On Mac:

/Library/Application Support/1E/Client/.sslcerts

Configuring the 1E certificate for macOS

The 1E Client for macOS devices supports the Configuring the Non-Windows 1E certificate using OpenSSL approach described above. Alternatively, the 1E Client for macOS also supports certificates stored within the macOS Key Store.

1E Server Setup will install 1E Catalog on the 1E server and ensure the server meets the requirements for installation.

Ensure the following URL is whitelisted: https://catalog.1e.com

This URL must be accessible from the 1E Server during the setup and running of 1E 1E Catalog. This enables the Catalog Update service to connect to the 1E Cloud Catalog and download the latest catalog entries.

1E Catalog may need additional configuration to support proxy servers, but this depends on the configuration you have in your current environment. Contact TeamViewer DEX Support if you need help doing this.