Version: 1
restore

Contents

Overview

First, install the Shopping Central server on a web server, then install a Shopping Receiver on every Configuration Manager site server which manages users and computers that you wish to manage using Shopping. Finally deploy the Shopping Agent to each computer that will be managed.

Normally the Shopping Central server connects to the top-level Configuration Manager site. For Configuration Manager 2012, this is a the Primary site in a single site system, or the CAS in a multi-site system

You must install a Shopping Receiver on the top-level Configuration Manager site server to enable:

  • OSD functionality (Configuration Manager 2012)
  • AppModel functionality (Configuration Manager 2012)

In a multi-site system, you can instead have one or more autonomous Shopping systems that connect to child primary sites, and manage the users and computers only within that part of the hierarchy. Each Shopping system is completely independent of the others, and requires its own supporting infrastructure. This approach is not recommended if your Configuration Manager system supports roaming between sites managed by different Shopping systems. 

The preparation required to install a single Shopping system is"

  1. Obtain a Shopping license key for the Shopping Central installation.
  2. Provision a Web server and SQL Server for Shopping Central:
  3. Create a DNS Alias for the Shopping Central Web server and SPNs:
  4. Active Directory considerations:
  5. Ensure installation, service accounts and groups have the necessary Configuration Manager rights.
  6. Configure MSDTC on relevant servers - see Remote Servers and Consoles need MSDTC configuration.
  7. Configure firewalls to support Networking.
  8. Integration considerations:

Installation accounts

  1. Shopping Central installer account: 
    • Must be a domain account 
    • Must be a member of the Shopping Administrators (ADMINACCOUNT) group
    • Must have local admin rights on the following servers, for example by being a member of its Administrators localgroup
      • Shopping Central server
      • Top-level Configuration Manager server
    • Must be a member of the SMS Admins local group on the top-level Configuration Manager server
      • This is normally achieved by making the installation account an Administrative user in the Configuration Manager Admin console
    • Requires one of the following sets of rights on the SQL instance hosting the Shopping database:
      • sysadmin (can be temporary)
      • ALTER ANY LOGIN and db_owner 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 the top-level Configuration Manager database database:
     
  2. Shopping Receiver installer account: 
    • 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 an Administrative user in Configuration Manager, with Full Administrator rights, unless the rights listed in Configuration Manager rights are provided as a prerequisite 
    • 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

  1. 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
     
  2. 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

Configuration Manager rights

Installation accounts require administrative rights as decribed in Installation accountsThe Receiver service account or group requires permissions in Configuration Manager, which are managed through the Configuration Manager Console, as described below.

Configuration Manager 2012

Use the XML file to create a security role and then assign each Receiver service account or the Receivers group. This is a one-time only manual procedure prior to installation of the first Receiver, which is usually on the top-level Configuration Manager Site.

ClassesPermissions
  • Application
  • Distribution Point
  • Distribution Point Group
  • Package
  • Site
  • Status Messages
  • Task Sequence Package
  • Users
  • Read
  • Collection
  • Configuration Item
  • Global Condition
  • Full

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 deployment notifications

To enable deployment notifications, the following settings must be made:

  • For Configuration Manager 2012
    • In the Configuration Manager Admin Console, enable the following under Administration → Site Configuration → Sites → <top-level Site> → Status Summarizers
      • Component Status Summarizer
      • Site System Status Summarizer
      • Application Deployment Summarizer 
      • Application Statistics Summarizer
    • In the top-level Configuration Manager Site database, ensure the Shopping Configuration Manager Database Access (SHOPPINGCONSOLESMSUSERS) group has 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 rights will be configured automatically during installation.
    • 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.

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 
  • Shopping Limited Database Admin Access
  • Shopping Configuration Manager Database Access
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 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 is referenced eleswhere 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 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 feature 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.

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 (e.g 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 Organisation 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 particular 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 Configuration Manager 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 shoppers 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 dual-forest Active Directory configurations. We describes these configurations, where Shopping components must be installed for each of these and the rules that must be followed when creating Shopping groups.

Dual-forest domain environments

Shopping supports dual-forest scenarios using root-level forest trusts and external trusts. The AD forests themselves may be single or multi-domain. When a root-level forest trust is used, install Shopping central 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   

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   

In both these instance, install the Shopping components 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, Admin console and database
    • Configure the Shopping installation accounts
  • On either AD forest, where appropriate, install the following on the accessible domains (shown in the diagrams above in orange):
    • Shopping receivers, client and end-user accounts (approvers etc)

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 ports 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

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 and its FQDN for the following accounts:

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

The following are examples of how to create SPNs for the Shopping Central service account.

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

The following are examples of how to create SPNs for the Shopping Central application pools. It the pools use Network Service, then specify the server's machine account. If the pools have been configured to use a domain service account then specify the account name.

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.

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 Security

Windows Authentication

Web-Windows-Auth
Web Server Application Development.NET Extensibility 4.5Web-Net-Ext45
ASP.NET 4.5Web-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 Features.NET Framework 4.5Net-Framework-45-Core
ASP.NET 4.5Net-Framework-45-ASPNET

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

 

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 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 e xpand Computers → My Computer → Distributed Transaction Coordinator → Local DTC.
  4. Right-click 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

Setting the security attributes for the DTC

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

AppClarity integration

To enable integration between Shopping and AppClarity, you must have AppClarity 4.6 or later installed.

AppMapping support in Shopping 5.3.100

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 is configured to be backwards compatible with AppClarity 5.0 and earlier versions. If you intend to integrate with AppClarity 5.1 (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.

Application Migration integration

If you are already using the existing AppMapping feature, there is no need to use the new Application Migration feature. If you do decide to use it, your existing migration rules will not work. We recommend you engage Support to discuss your requirements.

If you are new to Shopping, we recommend taking advantage of the new Application Migration feature. The process to install and integrate the new Application Migration feature is:

  1. Application Migration must already be installed in your environment and a service account needed to integrate the services for this feature must already exist.
  2. Integrating Shopping with Application Migration

Networking

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. TCP 135 and 445 are used to initiate communications and negotiate a dynamic RPC port. The dynamic range depends on the Windows OS version.

Shopping Receiver service expects the Configuration Manager SMS Provider role exists on the local server, and communicates with it using WMI (DCOM).
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

PortTrafficNotesConfigurable
TCP 80 (HTTP)OutboundFor browsers on clients to communicate with the Shopping central Website.Yes. If a port of other than port 80 is used, it must be specified on the URL used by shoppers 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 DirectoryNo

Ports used by Shopping agent

PortDirectionNotesConfigurable
TCP 8000 (HTTP)InboundFor browsers on clients to communicate with the Shopping agent to retrieve machine information. Yes, during the Shopping agent installation when you specify the WCF service URL. If you change the URL/port from its default value, you will also need to update the 1E Shopping Agent WCF Service URL setting on the Shopping Admin console settings page.

Sizing and deployment considerations

For optimum performance, we recommend the following:

For a single-server deployment

Maximum number of machines5,000
Benchmark configuration
Number of Shopping applications200
Maximum user logons per hour500
Maximum shopping requests per hour250
Application server
CPU cores4
RAM6 GB
SQL Server instance max memory1 GB
Disk space for database4.1 GB
ActiveEfficiency Scout
CPU cores1 (50%)
RAM250 MB
ActiveEfficiency server service
CPU cores2
RAM1.25 GB
Shopping server service
CPU cores1
RAM600 MB
ActiveEfficiency database
CPU cores1 (60%)
Database max memory625 MB
Disk space for database4.1 GB
Shopping database
CPU cores1 (40%)
Database max memory400 MB
Disk space for database50 MB
SQL Server HDD requirements
ActiveEfficiency database MDF90 MB
ActiveEfficiency database LDF50 MB
ActiveEfficiency database Temp DB MDF8 MB
ActiveEfficiency database Temp DB LDF1 MB
Shopping database MDF22 MB
Shopping database LDF10 MB
Shopping database TempDB MDF8 MB
Shopping database Temp DB LDF10 MB
For a distributed server deployment:

Maximum number of machines25,00050,000100,000200,000500,000
Benchmark configuration
Number of Shopping applications5001,0001,0002,0002,000
Maximum user logons per hour2,0004,0005,00010,00020,000
Maximum shopping requests per hour1,0002,0002,5005,00010,000
ActiveEfficiency Server
CPU cores34568
RAM4 GB5 GB5.5 GB6 GB12 GB
ActiveEfficiency Scout
CPU cores11124
RAM1 GB1 GB1.5 GB2 GB6 GB
ActiveEfficiency server service     
CPU cores23444
RAM1.5 GB2 GB2 GB2 GB3 GB
Shopping server
CPU cores33468
RAM4 GB4 GB6 GB8 GB16 GB
Database server
CPU cores234710
RAM4 GB7 GB9 GB11 GB16 GB
SQL Server instance max memory2 GB3 GB5 GB7 GB12 GB
Disk space for database4.25 GB4.5 GB5.5 GB6 GB8 GB
ActiveEfficiency database
CPU cores11112
Database max memory1.5 GB2 GB3 GB4 GB8 GB
Disk space for database4.1 GB4.1 GB4.2 GB4.3 GB4.8 GB
Shopping database
CPU cores12368
Database max memory500 MB1 GB2 GB3 GB4 GB
Disk space for database138 MB257 MB1.3 GB1.7 GB3.2 GB
SQL Server HDD requirements
ActiveEfficiency database MDF250 MB450 MB800 MB1.4 GB4 GB
ActiveEfficiency database LDF50 MB85 MB150 MB250 MB750MB
ActiveEfficiency database TempDB MDF8 MB8 MB8 MB8 MB8 MB
ActiveEfficiency database TempDB LDF1 MB1 MB1 MB1 MB1 MB
Shopping database MDF60 MB118 MB1052 MB1076 MB1230 MB
Shopping database LDF17 MB22 MB43 MB112 MB668 MB
Shopping database TempDB MDF11 MB20 MB36 MB75 MB246 MB
Shopping database TempDB LDF50 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 s 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 synchronisation 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 2GB 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.5MB for ActiveEfficiency Database for every 1000 devices and users added to the system. Note that the actual growth can vary depending on other factors.
  • Run the ActiveEfficiency Scout in its alternate mode when performing synchronization operations with ActiveEffciency to minimize the amount of data to what Shopping actually requires. This can be run using the 1E ActiveEfficiency Sync Manager tool.