1Summary

What you will need to prepare in advance of implementing Shopping 5.5.200 in your network. Typically, these are tasks that may take some time, depending on how your organization works. A more complete checklist of tasks is provided in Prerequisites.

ActiveEfficiency

ActiveEfficiency Server must be installed first before installing the Shopping Central server. The ActiveEfficiency Scout is also required to run in Alternate Sync mode in order to obtain machine and user data from Configuration Manager. Please refer ActiveEfficiency documentation for installation and configuration details.

1E Client

1E Client 4.1, or Tachyon Agent 3.2 or later, must be deployed to all in-scope clients with the Shopping module enabled, in order for users to access the Shopping self-service portal or use the Windows Servicing Assistant (WSA). 

The Tachyon Agent 3.3 and later, and 1E Client 4.1, also include a WakeUp client module which supports Wake-on-LAN as part of a 1E NightWatchman solution. 1E Client 4.1 also includes a Nomad client module.

All client modules and the Tachyon real-time features can be optionally enabled during deployment of the Client/Agent or after deployment by enabling features in its configuration file. You do not require a Tachyon license or any Tachyon server infrastructure unless you want to take advantage of Tachyon real-time features and applications. Please refer to Tachyon 4.1 - Implementing Tachyon for detailed information about implementing the full Tachyon infrastructure.

If you have TLS 1.0 disabled in your environment, then you must use Tachyon Agent 4.0 or 1E Client 4.1.

Shopping self-service portal

The Shopping module of the Tachyon Agent/1E Client provides support for users connecting to the Shopping Portal, by providing information such as the computer name which browsers are not able to provide. This feature is a direct replacement for the previously available Shopping Agent (no longer supported). You can optionally enable Loopback Exemption. 

When users connect to the Shopping web portal, Shopping needs get the latest details about the local computer. Shopping may already have details from the Configuration Manager database via ActiveEfficiency, but these need to be confirmed and updated. Browser standards only allow websites to get limited information about the user and computer, therefore the Shopping website needs to make loopback calls to the local computer via the Shopping client. The following browsers permit loopback calls by default:

  • All versions of Chrome
  • All versions of Firefox
  • Non-Metro UI based Internet Explorer browsers (including legacy Internet Explorer)

If your Shopping users are using Edge and Metro Internet Explorer browsers you must enable a Loopback Exemption to allow these browsers to make loopback calls. Exemption affects the browser as a whole and is not just restricted to the Shopping website. Before enabling this option, check your corporate security policy and be aware of the implications of allowing access between browsers and the local machine. By enabling loopback, you are only setting the Edge/Metro Internet Explorer browsers to the same level of security as other browsers which allow this setting already.

If you are running an unattended install, you can use MODULE.SHOPPING.LOOPBACKEXEMPTIONENABLED for all OS but it only works on Windows 8, 8.1, 10 and Windows Server 2012 R2 and later.

Shopping client only allows inbound connections to localhost (127.0.0.1) which prevents remote access.

Windows Servicing Assistant (WSA)

The Shopping module of the Tachyon Agent also provides Windows Servicing Assistant (WSA) which guides users through the preparation and execution of an OS deployment. It is a client-based wizard that enables users in the office or working remotely over VPN to initiate an OS upgrade or OS refresh (wipe-and-load) or to migrate data, settings and applications from an old PC to a replacement PC at their convenience. WSA Applications are managed through the Shopping Admin console. It has a dependency on 1E Nomad 6.3.201 or later, to manage content and storage of user state using custom Task Sequence steps that are implemented with Nomad. 1E Application Migration (including SLA Platform) is also required if you want to enable the WSA to migrate applications. Customers that have purchased the WSA are licensed to use Shopping, Nomad, and Application Migration, and can therefore take full advantage of the all WSA functionality.

Tachyon Agent versions offers different levels of support for WSA:

  • WSA in Tachyon Agent 3.2 provides basic features and works with Shopping 5.5.0
  • WSA in Tachyon Agent 3.3 provides the following and works with Shopping 5.5.100 and later:

    • Customization of all text strings
    • Wi-Fi support for Wipe and Load Destructive deployments
  • WSA in Tachyon Agent 4.0 and 1E Client 4.1 each provide the following WSA enhancements and work with Shopping 5.5.200:

    • Applications page includes all installed, normalized applications
    • Allow conditional download of Windows 10 upgrade packages
    • Check Windows 10 version readiness checks before upgrading
    • Perform In-place Upgrade compatibility check in WSA readiness checks
    • Allow Windows Servicing Assistant to exclude user state migration
    • Required for environments where TLS 1.0 is disabled

Self-Service OS Deployment

Please refer to Self-service Operating System deployment which explains the difference between the following:

  • Users shopping for ConfigMgr Applications (Task Sequences) in the same way as any other Shopping application
  • Users shopping for OSD Applications which run an OSD Wizard in the Shopping web portal to schedule an OS Deployment
  • Users shopping for WSA Deployment Applications which use a local client-based WSA Wizards to prepare and schedule an OS Deployment.
On this page:

Application Migration

Application Migration is a separately licensed product from 1E that replaces the Application Mapping feature in Shopping with a much more feature rich solution. The Application Mapping feature is still supported in Shopping 5.5, so you can continue to use it, however there are additional considerations if you are also upgrading AppClarity explained below under AppClarity integration.

Application Migration integration

When Shopping is integrated with Application Migration then the Shopping OSD Wizard and the Windows Servicing Assistant shows the user which applications will be migrated.

The process to install and integrate Application Migration is:

  1. Install the following:
    • 1E Catalog 1.2, SLA Platform 3.3 and Application Migration 2.5. Please refer to Application Migration 2.5 for details of its requirements.
    • Shopping 5.5
  2. Configure Shopping to integrate with Application Migration. Please refer to Integrating with Application Migration
  3. Configure mapping rules in Application Migration.

If Application Migration is replacing Application Mapping:

  • there is currently no automated method to migrate rules from Application Mapping to Application Migration. Please contact 1E if you require help with this (email Support@1e.com)
  • you can continue using AppClarity 5.x for license management but instead you may wish to consider using the web-based AppClarity 6.1, which can be installed on SLA Platform alongside Application Migration

AppClarity integration

Application Mapping is a legacy feature of Shopping 5.5 that requires AppClarity 5.2 instead of Application Migration. It provides support for Application Mapping steps in OSD Task Sequences, and product usage details for users in the Shopping My Software page. In addition to these features, AppClarity can be used to manage and control software product licenses, and collects product inventory and usage details using ActiveEfficiency.

Please refer to Integrating with AppClarity for configuration details.

AppMapping support in Shopping

From AppClarity 5.1, the Catalog – which is used to map and correctly identify installed applications – has become a separate component with a new schema. By default, Shopping 5.3.100 and later is configured to be backwards compatible with AppClarity 5.0 and earlier. If you intend to integrate with AppClarity 5.1 or 5.2 (whether through an upgrade or first time installation), you must run the Application Mapping Migration wizard so that application mapping works with the Catalog's new schema.

After running the Application Mapping Migration wizard Shopping will no longer be backwards compatible with previous versions.

These Shopping accounts must have integration services permissions enabled in the AppClarity console:

  • Shopping Central service account
  • Machine account for the server hosting the Shopping website (required when using AppClarity integration on the Administrator Copy Configuration page).
  • Shopping administrator(s)

AppClarity database and the AppClarity database server instance are mandatory fields when you integrate these products along with AppClarity Endpoint and AppClarity integration. Read only permissions must be granted to Shopping service account and Shopping Admin user/group account in the AppClarity database.

Licenses

Shopping and Windows Servicing Assistant are licensed separately. Both license keys must be provided when installing Shopping Central server.

Accounts needed to install Shopping

Shopping Central installation account

The user installing Shopping Central requires the following Service Accounts

  • Must be a domain user
  • Must be a member of the Shopping Administrators (ADMINACCOUNT) group
  • Must have local admin rights on the server on which Shopping Central will be installed. If the Shopping Central Service and Web components are to be installed on separate servers, the user installing them must have local admin rights on each server.
  • Must have local admin rights on the Configuration Manager site server. 
  • Must be a member of the Full Administrator role in Configuration Manager as the installer adds ConfigMgr Security rights for the Shopping Central Service Account.
  • Requires one of the following sets of rights on the SQL instance hosting the Shopping database
    • sysadmin (can be temporary for the duration of installation), or
    • ALTER ANY LOGIN (on the SQL server / instance) and db_owner (on the database) if the Shopping database is pre-created, or dbcreator if the installation will create the database
  • Requires one of the following sets of rights on the SQL instance hosting Configuration Manager database:
    • sysadmin (can be temporary for the duration of installation), or
    • ALTER ANY LOGIN and db_owner

Shopping Receiver installation account

The user installing the Shopping Receiver requires the following

  • Must be a domain account
  • Must have local admin rights on the Configuration Manager server, for example by being a member of the Administrators localgroup
  • Must have sysadmin rights on each SQL instance hosting the Configuration Manager database
  • Must be a member of the Full Administrator role in Configuration Manager
  • Useful to be a Shopping Administrator with access to the Sites node in order to select the Primary Site, otherwise another Administrator can complete that step after installation

Service accounts

Shopping Central service account

  • Must be a domain account with local admin rights on the Shopping server
  • Must have NTFS security
    • read and execute permissions on the Shopping program files installation folder
    • full permissions to the Shopping log folders
    • the above will be automatic if Shopping is installed using default locations on a default installation of Windows
    • the above security permissions are particularly relevant if you use non-default installer properties INSTALLDIR or LOGPATH
  • We recommend restricting the account with Deny logon locally
  • Must be a member of the Shopping Configuration Manager Database Access (SHOPPINGCONSOLESMSUSERS) group. If the Shopping Central installer account has permissions to add accounts to this group, then it will automatically add the account to the group during installation.
  • For AppClarity integration, must have integration services permission enabled from the AppClarity console 

Shopping Receiver service account

  • Each Receiver needs a service account, which can be either a dedicated or shared domain user account or Network Service
  • We recommend restricting the account with Deny logon locally
  • The Receiver service account must have local admin rights on the Site server

    • at the very least it must have read access to the binaries, and full permissions to the Receiver log folders
    • if you upgrade the Shopping Receiver with a different service account, it must have Read/Write permissions to %sysdrive%Programdata/1E or ~All Users/1E
  • Must have permissions in the Configuration Manager Console and its SQL database, depending on the version of Configuration Manager, as described below in Configuration Manager rights.

  • The Receiver service account must have local admin rights on client machines if reshopping and/or native policy refresh features are to be used. 

    • this is achieved by adding the service account to the Administrators localgroup on all clients, either directly, or indirectly by membership of an AD Security group. Either method can be achieved by using Group Policy Restricted Groups.

  • Installation of Shopping Central requires details of the Receiver service account or an AD Security group containing Receiver service accounts, so that Receivers can access the Central web service:

    • a shared service account can be used if all Receivers use the same account, and an AD group is not required
    • a domain security group must be used if each Receiver has its own service account, or uses Network Service, which must be members of this group
    • we recommend using a domain security group if other services need access to the Central web service, for example if Shopping API scripts are used by OSD Task Sequences, then the group should include the Configuration Manager Network Access account. This security group should be Universal, but can be global if only one domain is involved.

A key design decision is whether Shopping Receivers should use a single shared service account, individual service accounts, or Network Service. Either way, to allow new accounts to be added or existing accounts to be changed more easily, we recommend you include the Receiver accounts in an AD Security Group and use this group when granting access to each of the following:

  • Administrators localgroup on the local Configuration Manager site server, where the Receiver will be installed
  • Configuration Manager security role, as described below in Configuration Manager rights.
  • Administrators localgroup on clients
  • In the Shopping Central installer's Service Account screen

Microsoft System Center Configuration Manager

Installation accounts

The user installing Shopping Central or Shopping Receivers requires membership of the Full Administrator security role in Configuration Manager, as described in Accounts needed to install Shopping.

1E Shopping Receivers security role

The Receiver service account or group requires the following permissions in Configuration Manager.

ClassesPermissions
  • Application
  • Distribution Point
  • Distribution Point Group
  • Package
  • Site
  • Status Messages
  • Task Sequence Package
  • Users
  • Read
  • Collection
  • Configuration Item
  • Folder Class (new in CB1906)
  • Global Condition
  • Full

These permissions are defined in an XML file and can be imported using the Configuration Manager console to create a 1E Shopping Receivers security role. Each Receiver service account or the Receivers group can then be assigned to this role. This is a one-time only manual procedure prior to installation of the first Receiver.

When a receiver creates a collection for deploying an application it needs to specify its limiting collection. By default, that is either All Systems or All Users and User Groups. However, these defaults are configurable in the Receiver's config file. Other collections can be mapped if the Shopping RBAC feature is used. If these collections are known, specify them, otherwise select the All instances of the objects that are related to the assigned security roles option in the Security Scopes tab. For more information see Role based access control in Shopping.

Configuration Manager site databases

Shopping Central - the Shopping Central Service account (SVCUSER) must be a member of the Shopping Configuration Manager Database Access (SHOPPINGCONSOLESMSUSERS) group. This group requires a login with db_datareader rights and execute permission on the fn_GetAppState and fnGetSiteNumber functions.  If the Shopping Central installer has sufficient rights on the Configuration Manager database, then these database rights will be configured automatically during installation.

Shopping Receivers - in all Configuration Manager Site databases, ensure the Shopping Receiver service account has a login with db_datareader rights and execute permission on the fnGetSiteNumber function. If the Shopping Receiver installer has sufficient rights on the Configuration Manager database, then these rights will be configured automatically during installation.

Support for the Windows Servicing Assistant

To support Windows Servicing Assistant (WSA), the Shopping Web application pool service account requires Read-only Analyst security role in Configuration Manager. This is required to enable it to parse task sequences using WMI. Typically, the Shopping Web application pool service account runs in the context of Network Service, in which case if Configuration Manager and the Shopping Web service are installed:

  • on different servers then the computer$ account of the Shopping Web server must be added to the Read-only Analyst security role.
  • on the same server then the NT AUTHORITY\Network Service account should be added to the Read-only Analyst security role.

Also change the Security Scopes tab for the user from the default of Only the instances... to All Instances of the objects that are related to the assigned security roles, which will cover all existing and future security scopes. Alternatively, you can leave the default setting and add all the security scopes that you are using for task sequences and related content.

Configuration Manager deployment notifications

To enable deployment notifications, the following summarizers must be enabled in the Configuration Manager Admin Console (Administration → Site Configuration → Sites → <top-level Site> → Status Summarizers):

  • Application Deployment Summarizer 
  • Application Statistics Summarizer
  • Component Status Summarizer
  • Site System Status Summarizer

Active Directory security groups

AD security groups must be Universal if more than one trusted domain is involved, but can be Universal or Global if only one domain is involved. If your AD domain functional level is Windows 2000 server mixed mode then the AD security groups must be domain Global.

Shopping Console Access groups

Three separate AD groups are required to enable access to the Shopping Admin Console and optionally support the Shopping Console node security feature. 

  • Shopping Full Database Admin Access (SHOPPINGCONSOLEADMINUSERS)
  • Shopping Limited Database Admin Access (SHOPPINGCONSOLESMSUSERS)
  • Shopping Configuration Manager Database Access (SHOPPINGCONSOLEUSERS)
You cannot use the same group to serve all three roles, these must be handled using three separate groups. Any attempt to use the same group for more than one role will result in the installation failing with database errors and rolling back.

The Shopping Console node security feature is enabled by default, but can be disabled in the Shopping Console settings panel. If the Shopping Admin Console Node Security feature is to be used, then the Shopping Full Database Admin Access (SHOPPINGCONSOLEADMINUSERS) group must have Modify permissions in Active Directory to manage membership of itself and the other two Shopping Access groups in the table below. You can permission each group, or permission an OU which contains the groups.

If the Shopping Console node security feature is not used, then the groups should have the following membership. The names in brackets are the Shopping Central installer properties, which are referenced elsewhere in this documentation.

Shopping AD GroupMembersMember ofNotes

Shopping Full Database Admin Access (SHOPPINGCONSOLEADMINUSERS)

  • None
  • Used to grant access to the Shopping database.
  • If the Shopping Admin Console Node Security feature is to be used, then this group must have Modify permissions in AD, on itself, and the other two Shopping Console Access groups. This allows members of this group to add other administrators and configure security their rights in the Shopping Admin Console.

Shopping Configuration Manager Database Access (SHOPPINGCONSOLESMSUSERS)

  • None
  • Used to grant access to the Configuration Manager database.
  • This group requires db_datareader rights on the Configuration Manager database. If the Shopping Central installer account has rights to the Configuration Manager database, then it will grant rights to this group during installation.

Shopping Limited Database Admin Access (SHOPPINGCONSOLEUSERS)

  • None

 

  • None
  • Required for installation, but only used if the Shopping Console node security feature is used.

Shopping Administrator groups

These are accounts or groups that have administrator rights in the Shopping Admin Console and web portal.

In addition to the Shopping Access groups, you need three further role-based security groups. Shopping allows these groups to be specified as individual domain user accounts, but then you are restricted to only these users being administrators, and using the Shopping Admin Console Node Security to manage additional user accounts. If your organization prefers to manage access rights through AD or other identity managements system, then you should use groups and disable the Shopping Admin Console Node Security feature. The names in brackets are the Shopping Central installer properties, which are referenced elsewhere in this documentation.

Shopping AD GroupMembersMember ofNotes

Shopping Administrators (ADMINACCOUNT)

  • Shopping Full Database Admin Access (SHOPPINGCONSOLEADMINUSERS)
  • Shopping Configuration Manager Database Access (SHOPPINGCONSOLESMSUSERS)

  • This account/group contains users accounts of Shopping administrators responsible for managing applications in the Shopping Console and the Administration tab in Shopping Web portal.
  • This account/group has full rights to all features in the Shopping Admin Console.
  • This account/>group and any members must be email enabled. The Shopping Central installer will use this email address as the mail-from address used by Shopping Central when it sends emails to users and administrators. This Admin Email address can be changed later in the Shopping Admin Console.
  • If the Shopping Admin Console Node Security feature is used, then this account/group can add other administrators and configure security their rights in the Shopping Admin Console.
  • If the Shopping Central installer account has modify or write permissions on the Shopping Console Access groups, then the installer will automatically add this account/group as a member of the two Access groups during installation, otherwise this account/group will need to be added to Console groups prior to installation.
  • The name of this account/group cannot be changed after installation.

Reporting Managers (REPORTSACCOUNT)

  • Individual user accounts and groups
  • None
  • Can run reports from the Shopping Web portal
  • Does not need to be email enabled
  • The name of this account/group can be changed after installation.

Licensing Managers (LICENSEMGRACCOUNT)

  • Individual user accounts and groups
  • None
  • Gets email notifications when license thresholds and maximum counts are exceeded. 
  • This account/group and any members must be email enabled.
  • The name of this account/group can be changed after installation.

As Shopping makes extensive use of automated email processing, the accounts and groups must have email addresses defined in AD. Where groups are used, the member accounts must also have email addresses defined in AD.

When configuring an AD security group to have an email address, this does not mean it has to be changed to a Distribution group type; it must remain as a Security group type.

Shopping Receiver Account group

During a Shopping Central installation, you must provide details for a Receiver Account. Instead of specifying an account, we recommend you specify an AD Security group, which contains individual Receiver service accounts. See Shopping Receiver service account.

Active Directory Server

During a Shopping Central installation, you must provide details for an Active Directory Server.  This can be an AD domain controller or an actual domain name. By default, Shopping performs AD queries using the global catalog, in which case you can specify the Active Directory Server as the domain name or nominate a domain controller server that is a global catalog server. 

If the global catalog is not available or not required (for example, in a single domain environment) then select a domain controller with the primary domain controller (PDC) emulator FSMO role if it is well connected. The PDC emulator is the preferred domain controller because it manages account and group changes for the domain. If the PDC emulator role is transferred, then update the Active Directory Server setting in the Admin Console settings.

Groups and Organization Units

Shopping does not support mixed domain AD Groups, i.e. AD Groups in one domain that contain AD users, computers or groups from another domain. To use AD Groups with Shopping, ensure that the Groups and the objects it contains belong to the same domain. Nested OUs, up to 5 levels deep, are supported but it does not support Groups within OUs.

Multi-domain configurations

Shopping supports implementations that span multiple domains. During installation, Shopping must be pointed at a Configuration Manager server which is used as its main contact. A Shopping Receiver must be installed on that server and on all other Configuration Manager site servers that Shopping interacts with. The Shopping Central and Shopping Receiver components may be installed on different domains but you must configure the DNS settings as follows:

  • If the Shopping Central service and main Configuration Manager contact are hosted on different domains, you must ensure that the SMS Provider (returned by the Configuration Manager server used during installation) is resolved to the correct domain name before you install Shopping central. This can only be done if a DNS search suffix for the Configuration Manager domain is added to the TCP/IP stack for the Shopping Central server's network card.
  • If the Shopping Central service and Shopping Receiver are hosted on different domains, add the DNS search suffix for the Receiver's domain to the TCP/IP stack for the Shopping Central server's network card. This must be done before users on the domain is serviced by that Shopping Receiver.
  • DNS search suffixes are added on the DNS tab in the Advanced TCP/IP Settings for the IPv4 Properties of the Shopping Central server's network card.

Multi-forest configurations

Shopping is designed to cater for two types of multi-forest Active Directory configurations: root-level forest trusts and external trusts. Each trust type has different requirements for where Shopping components must be installed, and rules that must be followed when creating Shopping accounts and groups.

The AD forests may be single or multi-domain. Multi-domain considerations are described in Multi-domain configurations.

For both trust types, Shopping components are installed as follows:

  • On the AD forest where the Configuration Manager central site is located, install following on the domain where the trust originates:
    • Shopping Web and API, Central service, Shopping database, and Shopping Admin Console
    • Shopping installation accounts
  • On either AD forest, where appropriate, install the following on the accessible domains (shown in orange in the below diagrams):
    • Shopping Receivers, clients, and end-user accounts (for example Shopping approvers)

Root-level forest trust

When a root-level forest trust is used, install Shopping Central (Web, API and service) on the root domain of the forest. This is the forest where the Configuration Manager site used by Shopping as its central site is located. In this scenario, all domains in the trusted forest is accessible, in addition to all the domains in the local forest.

Root-level forest trusts

External trust

When an external trust is used, install Shopping central on the domain where the external trust originates. This is the forest where the Configuration Manager site used by Shopping as its central site is located. Shopping supports external trusts where these exist one-level down from the forest root domain. In this scenario, only the external trusted domain is accessible, in addition to the domains in the local forest. 

External trusts

Restrictions on multi-forest environments

Though Shopping supports the dual-forest domain scenarios illustrated above, there are specific restrictions on the configuration of groups to be used with Shopping and certain implications associated with the way that the domain and trust relationships work with it.

  • Groups must be uniform – they must only contain AD objects from the same domain and forest. All the contained users, machines or groups must be in the same domain and forest as the group itself. If you need to add objects from another domain or forest, add them to a group that belongs to that domain or forest.
  • Shopping only supports security type groups – you can only use security type groups with Shopping but they may have any scope type.
  • Installation domain and accounts – the domain specified during installation is set as the starting point for all AD searches. Any accounts used during installation must belong to that domain and associated forest. Node security users and groups added later using the Shopping Admin console must come from the same domain/forest specified during installation. All other AD groups used in Shopping may come from either forest.
  • Trust relationship and type – Shopping supports two-way trusts where there is an up-level trust between the domains. Both domain controllers in the supported dual forest scenarios must be Windows 2000 server or above.
  • Trusted domains must be configured correctly and the trusted domain exist – AD searches in Shopping is severely impacted if there is a trust relationship for a domain that no longer exists.

Shopping Website name

 DNS Alias

The Shopping Website is created under its own website using its own HTTP binding, it is not created under the default website. The Shopping Website binding uses a host header to differentiate its HTTP port from the default website. The host header is normally specified as the FQDN of the Shopping DNS Alias, which all users and computers accessing the Web Portal and Shopping API must use. Therefore, choosing a suitable name for the DNS Alias is perhaps the most important design decision you will make.

Ensure that all clients using the Shopping system are able to correctly resolve the DNS Alias using their DNS lookup methods. This is typically why the FQDN of the DNS Alias is used.

In DNS, you can create a CNAME or Host (A) record. The example below uses a CNAME alias of SHOPPING for the host server ACME-SRV6.ACME.LOCAL which results in a host header FQDN of SHOPPING.ACME.LOCAL.  In this case, the server's FQDN suffix is the same as the Alias FQDN's suffix, but they do not need to be the same.


Setting up the DNS lookup in the DNS manager

When installing Shopping Central, the installer setting IISHOSTHEADER is used to configure the HTTP binding on the Shopping Website, and the Console settings for the Web URL and API URL. The Web URL setting is used in Shopping emails.

It is possible to manually add additional HTTP bindings to the Shopping Website. For example you can install using the server's DNS Alias FQDN, and then manually add a second HTTP binding for the DNS Alias without the suffix. This would allow users to access the Shopping Portal using either name.

Service Principal Names

Service Principal Names (SPN) are attributes of AD accounts.  Servers and service accounts are able to automatically create and update their own SPNs if they have AD permissions. Normally server accounts have these permissions by default, therefore if a service is using Network Service built-in account, there is no need to create any SPN. However, user accounts typically do not have permission and you need to create or update the SPN manually using an account that does have the rights, such as a domain administrator account. You can create an SPN by editing the attribute directly in the AD service account object, or use the SetSPN utility. More information about SPNs can be found in Microsoft's knowledge base

SPNs must exist for the HTTP host header for the following accounts:

  • the account used for the Shopping application pool, which is normally the Network Service. (optionally: the Shopping Central service account)

The following is a example of how to create SPNs for the Shopping Central service account (assuming that the IIS application pools for Shopping have been configured to run as the  Shopping Central service account, this is considered a non-typical configuration ).

setspn -a http/shopping ACME\svc_ShoppingCtrl
setspn -a http/shopping.acme.local ACME\svc_ShoppingCtrl

The following is a example of how to create SPNs for the Shopping Central application pools. If the IIS application pools for Shopping use Network Service, then specify the server's machine account. (this would be the most common configuration

setspn -a http/shopping ACME-SRV6
setspn -a http/shopping.acme.local ACME-SRV6

To determine if SPNs exist for the Shopping Central service account and Network Service on the server itself:

setspn -l svc_ShoppingCtrl
setspn -l ACME-SRV6

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.

Shopping Central IIS configuration

The following roles, role services and features must be installed/enabled as a minimum. The Name column is the reference used in PowerShell commands.

In the case of .NET features we refer to 4.X in the Display Name, as X may be different depending on the server OS. The PowerShell Name always uses 45 instead of the actual version. Shopping supports .NET Framework 4.5 or later.

Role or Feature

Display NameName
Web ServerWeb Server (IIS)Web-Server
Web Server Common HTTP FeaturesDefault DocumentWeb-Default-Doc
Directory BrowsingWeb-Dir-Browsing
HTTP ErrorsWeb-Http-Errors
Static ContentWeb-Static-Content
HTTP RedirectionWeb-Http-Redirect
Web Server Health and DiagnosticsHTTP LoggingWeb-Http-Logging
Web Server PerformanceStatic Content CompressionWeb-Stat-Compression
Web Server SecurityWindows AuthenticationWeb-Windows-Auth
Web Server Application Development.NET Extensibility 4.XWeb-Net-Ext45
ASP.NET 4.XWeb-Asp-Net45
ISAPI ExtensionsWeb-ISAPI-Ext
ISAPI FiltersWeb-ISAPI-Filter
Web Server Management ToolsIIS Management ConsoleWeb-Mgmt-Console
IIS 6 WMI CompatibilityWeb-WMI
.NET Framework 4.5 (or later) Features.NET Framework 4.XNet-Framework-45-Core
ASP.NET 4.XNet-Framework-45-ASPNET

For

The following roles, role services and features should be removed/disabled.

ParentDisplay NameName
Web Server Common HTTP FeaturesWebDAV PublishingWeb-DAV-Publishing
The following PowerShell commands can be used to install relevant IIS roles and features on Windows Server 2012 R2 and later, and record the server configuration in a file.

Do this even if IIS is already installed because it will ensure all the required features and roles are installed.

 View Install-IIS.ps1 ...

Download...  

Configure IIS using PowerShell
Import-Module ServerManager

Get-WindowsFeature | Out-file ServerManager-1.txt

Install-WindowsFeature Web-Server,
Web-Default-Doc,
Web-Dir-Browsing,
Web-Http-Errors,
Web-Static-Content,
Web-Http-Redirect,
Web-Http-Logging,
Web-Stat-Compression,
Web-Windows-Auth,
Web-Net-Ext45,
Web-Asp-Net45,
Web-ISAPI-Ext,
Web-ISAPI-Filter,
Web-Mgmt-Console,
Web-WMI,
Net-Framework-45-Core,
Net-Framework-45-ASPNET
 
Uninstall-WindowsFeature Web-DAV-Publishing
  
Get-WindowsFeature | Out-file ServerManager-2.txt

Installing when TLS 1.0 is disabled

SQL Server Native Client 11.0 is referenced in database connection strings as SQLNCLI11. It provides a suitable ODBC (OLE DB) driver that supports TLS 1.1/1.2 necessary for the MSI installer, and is not required for .NET Framework applications.

Also known as SQL Server 2012 Native Client you can download the installer (sqlncli.msi) from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=50402, and then install the Client Components feature. This version supports SQL Server 2012, 2014, 2016 and 2017.

You can confirm the driver is installed using the ODBC Data Sources utility, as shown opposite.

If TLS 1.0 is disabled and you attempt to install without SQL Server Native Client 11.0 then the installer will fail with Error 27502. Could not connect to Microsoft SQL Server ... SSL Security error.


Remote Servers and Consoles need MSDTC configuration

If you are using a remote computer for any of the following, you must configure MSDTC on the Shopping Central server as well on the remote computer:

  • Installing a remote Shopping Admin Console
  • SQL Server hosting the Shopping database
  • Installing a remote Shopping Website with the Web Only option
  1. Ensure the Distributed Transaction Coordinator (MSDTC) service is enabled and running.
  2. Optionally use the registry import, which will set the values which you can then verify using the following steps.
  3. Start Component Services (comexp.msc) and expand Component Services → Computers → My Computer → Distributed Transaction Coordinator → Local DTC.
  4. Right-click on Local DTC and from the context menu, choose Properties.
  5. Select the Security tab and enable the following, leaving other settings as default.
    • Network DTC Access
    • Allow Remote Clients
    • Allow Inbound
    • Allow Outbound
    • Mutual Authentication Required
    • Enable XA Transactions
  6. Click OK – if any changes were made this will restart the MSDTC service.
  7. If you used the registry import, you will need to restart the MSDTC service.
Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC]
"FallbackToUnsecureRPCIfNecessary"=dword:00000000
"AllowOnlySecureRpcCalls"=dword:00000001
"TurnOffRpcSecurity"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\Security]
"NetworkDtcAccess"=dword:00000001
"NetworkDtcAccessClients"=dword:00000001
"NetworkDtcAccessAdmin"=dword:00000000
"NetworkDtcAccessInbound"=dword:00000001
"NetworkDtcAccessOutbound"=dword:00000001
"NetworkDtcAccessTransactions"=dword:00000001
"NetworkDtcAccessTip"=dword:00000000
"XaTransactions"=dword:00000001
"LuTransactions"=dword:00000000


Networking

Connections diagram

There are several ports that are used in the Shopping application. These must be enabled in the firewalls for the relevant computers. The distribution of Shopping components and their associated ports is illustrated as follows:


Ports used by the Shopping Website

PortTrafficNotesConfigurable
TCP 80 (HTTP)InboundFor browsers on clients and Shopping receivers to communicate with the Shopping Website.Yes, during installation when specifying the IIS port used by the Website.
TCP 1433 (ADO.NET)OutboundCommunication with a remote Shopping database. Yes, during installation when specifying the SQL Server instance used by the Shopping database.
TCP 389 (LDAP)Outbound

Communication with Active Directory to verify user, computer and AD groups and resolution of each user's manager and email address.

Ensure that all secured (636 and 3269) and unsecured (389 and 3268) ports on the domain controller are not blocked. If, for any particular reason, they are restricted, then all the servers hosting Shopping components must be added to the exception list so that Shopping can execute the specific LDAP calls.
No
TCP 636 and 3269 (LDAPS)Inbound/Outbound

Communication with Active Directory.

Ensure that all secured (636 and 3269) and unsecured (389 and 3268) ports on the domain controller are not blocked. If, for any particular reason, they are restricted, then all the servers hosting Shopping components must be added to the exception list so that Shopping can execute the specific LDAP calls.
No

Ports used by the Shopping Central Service

PortTrafficNotesConfigurable
TCP 80 (HTTP)OutboundCommunication with a remote ActiveEfficiency Server.Yes, during installation when specifying the location of the ActiveEfficiency server.
TCP 389 (LDAP)OutboundCommunication with Active Directory to verify user, computer and AD groups and resolution of each user's manager and email address.No
TCP 1433 (ADO.NET)OutboundCommunication with a remote Shopping database.Yes, during installation when specifying the SQL Server instance used by the Shopping database.
TCP 1433 (ADO.NET)OutboundCommunication with the remote Configuration Manager Site database if the Shopping RBAC feature is not used. RBAC uses WMI (DCOM) instead of SQL.Yes, indirectly. The port is determined by querying the SMS Provider on the Configuration Manager site server
WMI (DCOM) TCP 135 and 445 (initially)OutboundRemote access to the SMS Provider role on the Configuration Manager site server. TCP 135 and 445 are used to initiate communications and negotiate dynamic RPC and MSDTC ports. The dynamic ranges depend on the Windows OS version.No
TCP 25 (SMTP)OutboundCommunication with a remote SMTP gateway to send emails.Yes, during installation when specifying the SMTP server.
TCP 110 (POP3)OutboundThis port is required in a lab environment only if Exchange is not available and a remote POP3 server is used instead.Yes, during installation when specifying the SMTP server.
TCP 8335OutboundCommunication with a remote AppClarity server. This is only required only if Shopping uses AppClarity integration.No
TCP 636 and 3269 (LDAPS)Inbound/OutboundCommunication with Active DirectoryNo

Ports used by the Shopping Admin Console

Required if the Shopping Admin console is installed on a client remote from the Shopping central server.

PortTrafficNotesConfigurable
TCP 1433 (ADO.NET)OutboundCommunication with a remote Shopping database.Yes, when specifying the SQL Server instance used by the Shopping database.
TCP 1433 (ADO.NET)OutboundCommunication with the remote Configuration Manager site database if the Shopping RBAC feature is not used. RBAC uses WMI (DCOM) instead of SQL.Yes, indirectly. The port is determined by querying the SMS Provider on the Configuration Manager Site server
TCP 389 (LDAP)OutboundCommunication with Active Directory to verify user, computer and AD groups and resolution of each user's manager and email address.No
WMI (DCOM) TCP 135 and 445 (initially)OutboundRequired for remote access to the SMS Provider role on Configuration Manager site servers. TCP 135 and 445 are used to initiate communications and negotiate a dynamic RPC port. The dynamic range depends on the Windows OS version. No
TCP 636 and 3269 (LDAPS)Inbound/OutboundCommunication with Active DirectoryNo

Ports used by the Shopping receiver

The Shopping Receiver is expected to be installed on the Configuration Manager Site server that has a local SMS Provider role.

PortTrafficNotesConfigurable
TCP 80 (HTTP)OutboundCommunication with the Shopping central Website.Yes, during the Shopping receiver installation when you specify the location of the Shopping central server.
WMI (DCOM) TCP 135 and 445 (initially)Outbound

Required for communication with:

  • Remote clients when using the policy refresh and reshopping features
  • Configuration Manager SMS Provider
Shopping Receiver service expects the Configuration Manager SMS Provider role exists on the local server, and communicates with it using WMI (DCOM).

TCP 135 and 445 are used to initiate communications and negotiate a dynamic RPC port. The dynamic range depends on the Windows OS version.

No.
TCP 1433 (ADO.NET)Outbound

Communication with the Configuration Manager site database, if remote.

In addition, if the Configuration Manager site database is on the default instance of SQL Server and using a custom port, you must configure a SQL alias using both the 32-bit and 64-bit versions of cliconfg.exe described in our KB. This is not applicable if the database is on a named instance.
Yes, indirectly. The port is determined by querying the SMS Provider on the local server.

Ports used by Shopping clients

The following table is for the Shopping client. It does not include ports required for other 1E products (for example Nomad, WakeUp and Tachyon) nor does it list ports required by Microsoft's Configuration Manager.

PortTrafficNotesConfigurable
TCP 80 (HTTP)Outbound

For browsers on clients to communicate with the Shopping central website (Shopping Portal).

http://<ShoppingCentralServer>/shopping

Yes. If a port of other than port 80 is used, it must be specified on the URL used by users when connecting to the Shopping Website.
WMI (DCOM) TCP 135 and 445 (initially)InboundRequired by remote Shopping receivers when using the policy refresh and reshopping features. TCP 135 and 445 are used to initiate communications and negotiate a dynamic RPC port. The dynamic range depends on the Windows OS version.No.
SMTP and POP3OutboundThese ports are required in a lab environment only if Exchange is not available, and an alternative email application is used to send and receive emails.Yes.
TCP 389 (LDAP)OutboundCommunication with Active Directory to verify user, computer and AD groups and resolution of each user's manager and email address.No
TCP 636 and 3269 (LDAPS)Inbound/OutboundCommunication with Active Directory.No
TCP 8000 (HTTP)Inbound (loopback)For browsers on clients to communicate with the Shopping agent to retrieve machine information. 

Yes. You specify the port in the 1E Tachyon Agent loopback URL setting in the Shopping Console.

On startup, the Shopping client queries the following URL to get the loopback URL. http://<ShoppingCentralServer>/shopping/WindowsServicingAssistant/GetTachyonAgentUrl

Sizing and deployment considerations

For optimum performance, we recommend the following:

Single-server deploymentDistributed server deployment

Maximum number of machines5,00025,00050,000100,000200,000500,000
Benchmark configuration
Number of Shopping applications2005001,0001,0002,0002,000
Maximum user logons per hour5002,0004,0005,00010,00020,000
Maximum shopping requests per hour2501,0002,0002,5005,00010,000
Combined Application Server (total including SQL Server)
CPU cores (total)4
RAM (total)6 GB
ActiveEfficiency Server (total)ActiveEfficiency Server (total)
CPU cores334568
RAM1.5 GB4 GB5 GB5.5 GB6 GB12 GB
ActiveEfficiency Server service
CPU cores223444
RAM1.25 GB1.5 GB2 GB2 GB2 GB3 GB
ActiveEfficiency Scout
CPU cores1 (50%)11124
RAM250 MB1 GB1 GB1.5 GB2 GB6 GB
Shopping Server serviceShopping Server (total)
CPU cores133468
RAM600 MB4 GB4 GB6 GB8 GB16 GB
Database Server (total)Database Server (total)
CPU cores (total)1234710
RAM (total)3 GB4 GB7 GB9 GB11 GB16 GB
SQL Server instance max memory (total)1 GB2 GB3 GB5 GB7 GB12 GB
Disk space for database (total)4.16 GB4.25 GB4.5 GB5.5 GB6 GB8 GB
ActiveEfficiency database
CPU cores1 (60%)11112
SQL Server instance max memory625 MB1.5 GB2 GB3 GB4 GB8 GB
Disk space for database4.1 GB4.1 GB4.1 GB4.2 GB4.3 GB4.8 GB
Shopping database
CPU cores1 (40%)12368
SQL Server instance max memory400 MB500 MB1 GB2 GB3 GB4 GB
Disk space for database60 MB138 MB257 MB1.3 GB1.7 GB3.2 GB
Database sizes
ActiveEfficiency database MDF90 MB250 MB450 MB800 MB1.4 GB4 GB
ActiveEfficiency database LDF50 MB50 MB85 MB150 MB250 MB750 MB
ActiveEfficiency database TempDB MDF8 MB8 MB8 MB8 MB8 MB8 MB
ActiveEfficiency database TempDB LDF1 MB1 MB1 MB1 MB1 MB1 MB
Shopping database MDF22 MB60 MB118 MB1052 MB1076 MB1230 MB
Shopping database LDF10 MB17 MB22 MB43 MB112 MB668 MB
Shopping database TempDB MDF8 MB11 MB20 MB36 MB75 MB246 MB
Shopping database TempDB LDF10 MB50 MB97 MB190 MB371 MB1057 MB

Recommendations

  • Servers can be deployed either on physical or virtual machines. For deployment on a virtual machine, assign the CPU cores at 100% virtual machine reserve
  • If network usage during the synchronization is a concern, for environments with 25,000 or more computers, we suggest a dedicated 1Gbps standard Ethernet connection between the servers (Scout, ActiveEfficiency and the Shopping server), with each server being multi-homed (i.e. 2 x NICs) so that the Shopping synchronization traffic between the servers can travel over this dedicated network and not compete for bandwidth
  • Database server:
    • We recommend you deploy data, logs and TempDB on separate physical disks
    • The database RAM recommendations are strictly for the maximum server memory to be allocated to the database instance and an additional 2 GB RAM is required for the operating system
    • Configure SQL Server with maximum server memory limit and not at the defaults to consume unlimited memory
    • Assuming there are in total 100k users and machines across the estate, the database growth on an average is about 7.5 MB for ActiveEfficiency Database for every 1000 devices and users added to the system. Note that the actual growth can vary depending on other factors.
  • ActiveEfficiency Scout is only required for AppClarity and Shopping. If ActiveEfficiency is not being used for AppClarity, then run the ActiveEfficiency Scout sync in its alternate mode to minimize the amount of data to what is required by Shopping. Scout mode is configured using the 1E ActiveEfficiency Sync Manager tool.