Shopping 6.1

If you want to use the Tachyon-related features - client-side Order Tracking and Tachyon Instruction Applications - you will need:

You will need a Tachyon license that covers the Shopping-specific instructions if you want to use the client-side features of Shopping's Order Tracking feature. Contact 1E for a Shopping 6.1 addition to your Tachyon license if you do not already have it.

In Tachyon, you will also need:

To prepare for integration with Tachyon please refer to Enabling Tachyon integration. That page includes details on manually adding the account and Shopping-specific instruction to Tachyon. It also shows how to define the Shopping Administrator role, configure the Shopping Tachyon consumer and modify the database to change the consumer workflow.

1E Client 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). 1E Client also includes the following:

Client modules can be optionally enabled during deployment of 1E Client or after deployment by enabling features in its configuration file.

The Shopping module of the 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.

The Shopping module of the 1E Client 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.

WSA features have the following 1E product dependencies:

Customers that have purchased the WSA license can use Shopping, Nomad, and Application Migration, and can therefore take full advantage of the all WSA functionality.

The following lists are combinations of products compatible with Shopping 6.1:

The following WSA features are available with the above product versions.

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

Application Migration is a separately licensed product from 1E that replaces the Application Mapping feature in Shopping with a much more feature rich solution.

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

Application Migration replaces Application Mapping:

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.

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

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. The permissions for the 1E Shopping Receivers role were changed in Shopping 5.6 to include support for Configuration Manager client notification. You will need to import one of the following files, depending on your Configuration Manager version:

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

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.

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

In the Configuration Manager Admin Console, the following summarizers must be enabled in the Configuration Manager Admin Console (Administration → Site Configuration → Sites → <top-level Site> → Status Summarizers) settings must be made:

To support Windows Servicing Assistant (WSA), the Shopping Web application pool service account requires the Read-only Analyst security role in Configuration Manager. This is required to enable it to parse task sequences using WMI. This is a one-time only manual procedure prior to after installation of Shopping Central.

Import the 1E Shopping Central Security Role.xml file into the Configuration Manager console to create a role called 1E Shopping Central. This role has the same permissions as the Read-only Analyst security role.

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:

You must 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.

The user installing Shopping Central requires the following:

The user installing the Shopping Receiver requires the following

If you use Shopping's ConfigMgr integration, you will need at least one Shopping Receiver.

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

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.

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.

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.

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.

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.

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.

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.

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.

From Shopping 6.1 the Shopping Central installer defaults to configuring an HTTPS site, this means that a Shopping Server certificate is required.

Only one Web Server certificate is required. This certificate must be provided on the server prior to installation of Shopping.

The Web Server certificate requires the minimum of the following:

The Shopping Web Portal and API are created under the Shopping website, they are not created under the Default Web Site. The website has an HTTPS binding, using a host header - 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.

When installing Shopping Central, the installer setting IISHOSTHEADER is used to configure the HTTPS 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/S bindings to the Shopping Website. Any HTTPS bindings you add must also exist in the Shopping server certificate. For example, if you are adding an HTTP binding you can install using the server's DNS Alias FQDN, and then manually add a second HTTPS binding for the DNS Alias without the suffix. This would allow users to access the Shopping Portal using either name.

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 HTTPS host header for the following accounts:

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 -s HTTPS/shopping ACME\svc_ShoppingCtrl
setspn -s HTTPS/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 -s HTTPS/shopping ACME-SRV6
setspn -s HTTPS/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.