Introduction

The Akumina PeopleSync V6/Cloud application synchronizes user properties for the following functionalities:

• Personalization and targeting (Persona) 
• Akumina Workspaces 
• Leveraging AD Groups in SharePoint Security Groups to provide permissions in AppManager 
  • Activity Stream  
• Social Features such as Comments, Reactions, and Notifications 
• Company Directory

 The following data sources are supported out of the box but can be configured to synchronize any data source with code development and configuration:. 

• Azure Active Directory 
• Okta 
• SharePoint User profile data (On-Premises) 
• Any custom sources (Configuration required) 

Note:  you can configure to synchronize more than one data source and merge the properties into a single store. 

Dataflow Diagram 

New Changes in V6/Cloud 

PeopleSync V6/Cloud application has several new changes related to configuration and synchronized properties.  

• By default the "FetchProperties" > "LargeContentProperties" does not fetching “AllProperties” for a user.  If "AllProperties" is required, people sync does support it for backward compatibility, "AllProperties" can be added to the Tenant specific configuration for the FetchProperties > "LargeContentProperties" .
• Property key casing and names have changed in V6/CloudPeopleSync.  For a list of valid Azure AD Graph

  (v1.6) properties, visit

  https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-property-differences. 
• For  OwnedDevices / RegisteredDevices - we have expanded the available properties.  On the image below see the new device properties on the left compared to earlier people sync versions of device properties on the right.

• Introduced tenant level “FetchOptions” for multitenant environments to overwrite global “FetchOptions”. Refer to “FetchOptions” section below for more information.
• Added a new configuration “FetchProperties” > “BooleanProperties to convert any Boolean string to Boolean value. Refer “FetchProperties” section below for more information.
• PeopleSync application is migrated from .NET Core 6.0 to .NET 8.0.
  • Prerequisite: People sync requires .NET Core 8.0.x or greater when running on a VM, visit https://dotnet.microsoft.com/en-us/download/dotnet/8.0 to downloads and install.
• The configuration file format has been modified compared to the previous version. So, when you move into PeopleSync V6 version, configuration file should be modified accordingly. Below are highlighted changes in configuration.
  • New property “TrackingConnectionString” is added to configure and log traces on application insights instead of flat file on server.
  • “StorageConfiguration” and “TenantConfigurations” sections are moved inside of new section called “Environments”. “StorageConfiguration” is also a new section, and this will be used to group storage and search service properties. You can refer below mentioned configuration format to know on properties should have inside “StorageConfiguration”.
  • Refer below screenshots to compare PeopleSync V5 and V6 configurations.
• To make it easier configuration properties are grouped. Below finds the new configuration Json format.

 

{ 

  "StorageConnection": "", 

  "TrackingConnectionString": " InstrumentationKey=************;IngestionEndpoint=https://*******.in.applicationinsights.azure.com/;LiveEndpoint=https://******.livediagnostics.monitor.azure.com/", 

  "AppInsightLocalAuthDisabled": false,

  "SyncConfiguration": { 

   "ContinueOnSchedule": false, 

   "ExitConsoleWhenDone": true, 

   "ResumeOnError": true, 

   "ScheduleIntervalInSeconds": 60, 

   "MaxRetryAttempt": 3, 

   "QueueItemVisibilityTimeoutInMin": 15, 

   "RetryDelayInMilliseconds": 1000, 

   "SamplingCount": 1000, 

   "SamplingPageCount": 1000, 

   "PersonaDeleteDelayInMins": 0, 

   "StorageAssemblyType": "Akumina.PeopleSync.Storage.CosmosDb.SqlApi, Akumina.PeopleSync.Storage.CosmosDb.SqlApi.Storage", 

   "QueueAssemblyType": "Akumina.PeopleSync.Storage.AzureStorage, Akumina.PeopleSync.Storage.AzureStorage.CloudQueueAction", 

   "PersonaAssemblyType": "Akumina.PeopleSync.Storage.AzureStorage, Akumina.PeopleSync.Storage.AzureStorage.PersonaStorageClient", 

   "SearchAssemblyType": "Akumina.PeopleSync.Storage.AzureStorage, Akumina.PeopleSync.Storage.AzureStorage.SearchAdmin", 

   "SyncSourceAssemblyType": "Akumina.PeopleSync.AzureActiveDirectory, Akumina.PeopleSync.AzureActiveDirectory.SyncSource", 

   "SyncUserPreferenceAssemblyType": "Akumina.PeopleSync.Storage.AzureStorage, Akumina.PeopleSync.Storage.AzureStorage.UserPreferenceStorage", 

   "MetricsAssemblyType": "Akumina.PeopleSync.Storage.AzureStorage, Akumina.PeopleSync.Storage.AzureStorage.Metrics", 

   "SubscriptionProvisioningAssemblyType": "Akumina.Subscriptions, Akumina.Subscriptions.SubscriptionProvisioning", 

   "CustomFilterAssemblyType": "" 

  }, 

  "FetchOptions": { 

    "SyncUsers": true, 

    "SyncGroups": true, 

    "SyncTags": false, 

    "SyncTypes": false, 

    "SyncUsersAssignedToNoGroups": true, 

    "TrackUserGroupChange": true, 

    "TrackUserPersonaChange": true, 

    "MergeGroupFieldsToUserGroup": true, 

    "CollectMetrics": true, 

    "SyncUserGroupUsingGroup": false, 

    "TrimDuplicates": true, 

    "SecondarySourceSyncAsFull": false, 

    "SecondarySourceAsMergeOnly": false 

  }, 

  "FetchProperties": { 

    "TagExtension": "groupname", 

    "TypeExtension": "groupuser", 

    "UserProperties": "", 

    "UserExtendedProperties": "", 

    "GroupProperties": "", 

    "PersonaUserProperties": "", 

    "UserGroupUserProperties": "", 

    "SkipGroups": "", 

    "SkipUsers": "", 

    "LargeContentProperties": "DirectReports", 

    "ExpandProperties": "", 

    "ConvertValueToLowerCase": "userPrincipalName,mail,userEmail", 

    "DateTimeOffsetProperties": "createdDateTime" 

  }, 

  "EmailSettings": { 

    "SmtpHost": "", 

    "SmtpPort": "", 

    "SmtpUser": "", 

    "SmtpPassword": "", 

    "SendUsingAppManager": false, 

    "NotifyTo": "", 

    "NotifyFrom": "" 

  }, 

  "Environments": [ 

    { 

      "Name": "default", 

      "StorageConfiguration": { 

        "AzureStorageConnectionString": "", 

        "QueueName": "akadqueue", 

        "RootBlobContainer": "akad", 

        "PeopleDataEntityPrefix": "akad", 

        "SearchIndexPrefix": "akad", 

        "FieldNameCasing": "Mixed", 

        "SingleContainerName": "users", 

        "StoreInSingleContainer": true, 

        "UsingSaaS": true, 

        "KeywordAnalyzer": "department_keyword,jobTitle_keyword" 

      }, 

      "TenantConfigurations": [ 

        { 

          "TenantId": "", 

          "ApplicationId": "", 

          "ApplicationSecret": "", 

          "PersonaFieldFiles": [ 

            "" 

          ], 

          "AkuminaUrls": [ 

            { 

              "AppManagerUrl": "", 

              "AppManagerQueryKey": "" 

            } 

          ], 

          "FieldsMappingSource": "fieldsmapping.aad.json", 

          "CustomFilterAssemblyType": "" 

        } 

      ] 

    } 

  ] 

} 

 

Download Links 

Executable from Virtual Machines:  

https://akumina.azureedge.net/interchange/PeopleSync /PeopleSync_v6.zip 

Executable from Web Jobs: 

https://akumina.azureedge.net/interchange/PeopleSync /PeopleSync_v6_webjob.zip  

Required Azure Active Directory  "Microsoft Graph" Application Permissions

In order to synchronize data from Azure Active Directory, certain "Microsoft Graph" permissions are required. Visit Graph API Connection for Azure AD, to learn more about the required graph permissions for People Sync and to configure permissions on the associated Graph App.

Configuring PeopleSync  

NOTE: If you have Multiple AppManagers and they are all interfacing to the same O365 tenant, then you need only one PeopleSync to run. AppManagers will use the same PeopleSync EntityPrefix, AzureSearchServiceName and AzureSearchServiceApiKey keys. If your AppManager’s websites are interfaced to different Azure Tenants, then you will need to generate an Azure “Search Service” for each AppManager pointing to a different Tenant.  Optionally you may use different prefix to leverage the same cognitive search investment. 

People Sync V6/Cloud Config Files 

When the people sync executes it looks in the config.json file for the people data configuration.  Akumina provides several config files, based upon where your data is coming from and where the results are stored. 

To change the config.json, backup the original config.json file and rename the appropriate configuration file to config.json.  Example, if people sync data is coming from Azure AD and the data is to be stored in Azure Storage Tables, then rename config.azuretable.json to config.json and start configuring people sync.  

 

Config File	Description
config.json	New in V6/Cloud, the default file, used when people sync is executed,  synchronizes data from AAD and stores the data to Cosmos Database (SQL API’s)
config.azuretable.json	After renaming this to config.json, this config sychronizes data from Azure Active Directory and stores the data to Azure Table
config.SharePoint.json	SharePoint On-Premises instances use this configuration file (after it has been renamed to config.json).  This config, synchronizes data from SharePoint UserProfileSerice and stores the data to a flat file defined in this config's property "UploadPath" (NOTE:  this path must match the value in the interchange.settings.config file key "tempuploadpath").  If you need load balancer then these file folders should be on a shared disk.
config.okta.json	After renaming this to config.json, this configuration file synchronizes data from Okta and store data in Azure Table or Azure Cosmos

 

Connection Properties 

Connection properties are values such as the Azure Storage, Cosmos Service, Azure Search Service connections,  as well as Application Insight for Dashboard reporting and AppManager logging.  These values are recommended to be stored in Key Vault.  If the values are stored in Key Vault then only the "RemoteStorageConnection"  would need to remain and be configured in the people sync's config.json file, set to the Key Vault URI.  

Configuring Key Vault Using the Akumina Template

Akumina does not require plain text connection string, instead store them in Key Vault value and specify the Key Vault URI in the config.json.  Please note if running on a VM or WebApp you must enable System Identity and add required permissions on the Key Vault for the objectId.

Create a JSON in this format, please note only the following fields are supported at this time through Key Vault:

{

"RemoteStorageConnection": "",

"ExternalConnection": {

"EndpointUrl": "",

"Database": "akcontainers"

},

"AzureSearchServiceName": "",

"AzureSearchServiceApiKey": "",

"InstrumentationKey":"",

"AppInsightAppId":"",

"AppInsightApiKey":"",

"FuncAppInsightAppId":"",

"FuncAppInsightApiKey":"",

"StoreInSingleContainer": "true",

"PrimaryRedisConnectionString":"",

"SecondaryRedisConnectionString":"",

"TokenStoreEntityName":"",

"BlobStoreContainerName":""

}

Where to acquire values for the Key Vault keys

Key	Description
RemoteStorageConnection	From Azure Portal – This is the Storage Account > Access Keys>ConnectionString or if using "Key vault" the "Secret Identifier".   Format for Keyless storage account "AccountName=xxxx;EndpointSuffix=xxx.yyy.zzz"
ExternalConnection	Used in V5+, array of items that make up the connection to the database to store the people sync data.   Format for Keyless cosmos DB account { "EndpointUrl": "", "Database": "akcontainers", "SubscriptionId":"", "ResourceGroup": "" }
External Connection - "EndpointUrl"	Used in V5+, the EndpointUrl - Comes from Cosmos DB "Settings" > Keys > value of the "PRIMARY CONNECTION STRING"
External Connection - "Database"	Used in V5+, the "Database" value comes from the container name for this database. This should always be set to "akcontainers"
AzureSearchServiceName	This will be the "Name" of the Azure Search Service configured in the Azure Portal to support this people sync.
AzureSearchServiceApiKey	This is the "Primary admin key" for the Azure Search Service configured to support this people sync.
InstrumentationKey	On the Supported AppInsights, click on Overview, copy and paste the "Instrumentation key".
AppInsightAppId	On the Supported AppInsights, click on "API Access", copy and paste the "Application ID".
AppInsightApiKey	On the Supported AppInsights, click on "API Access", click on "Create API Key", copy and paste the key
FuncAppInsightAppId	Used in V5+, on the Supported AppInsights created to support the function apps, click on "API Access", copy and paste the "Application ID".
FuncAppInsightApiKey	Used in V5+, on the Supported AppInsights, created to support the function apps, click on "API Access", click on "Create API Key", copy and paste the key
StoreInSingleContainer	true
PrimaryRedisConnection	Primary connection string (StackExchange.Redis) - Redis Cache associated with the AppManager web app resource
SecondaryRedisConnectionString	Secondary connection string (StackExchange.Redis) - this is optional - Redis Cache associated with the AppManager web app resource
TokenStoreEntityName	In the resource associated storage container this is the table name
BlobStoreContainerName	In the storage container this is the Blob container name

 

• Create a Key Vault secret then set the value to above JSON.
• Set the Access Policy on the Key Vault (using Configure from template = Key, Secret, & Certificate Management) and grant the permission to the appropriate VM or webapp where people sync is to run.
• Open PeopleSync config.json and update the AzureStorageConntetionString with the appropriate URI.

Config.json Connection Properties

Property	Type	Default	Description
AzureStorageConnectionString	String		From Azure Portal – This is the Storage Account > Access Keys>ConnectionString or Key Vault.  For storing the connection string in Key Vault you can specify the Key Vault URI – example if running as a webjob. (This is the same connection string found in the interchange.setings.config file see this key value:  akumina:RemoteStorageConnection).  To configure Key Vault, please review "Configuring Key Vault" section of this article below.   Format for Keyless storage account "AccountName=xxxx;EndpointSuffix=xxx.yyy.zzz"
ExternalConnection	JSON		"ExternalConnection": { "EndpointUrl": "", "Database": "" },If using the Key Vault template above then this section of the config should be removed since these items are defined in the Key Vault template.Else, these values are used when you are writing data to Cosmos DB.The EndpointUrl - Comes from Cosmos DB "Settings" > Keys > value of the "PRIMARY CONNECTION STRING"The "Database" value comes from the container name for this database. This should always be set to "akcontainers"   Format for Keyless cosmos DB account { "EndpointUrl": "", "Database": "akcontainers", "SubscriptionId":"", "ResourceGroup": "" }
AzureSearchServiceName	String	“”	Remove if using Key Vault template defined above.  Else, this will be the "Name" of the Azure Search Service configured in the Azure Portal to support this people sync.
AzureSearchServiceApiKey	String	“”	Remove if using Key Vault template defined above. Else, this is the "Primary admin key" for the Azure Search Service configured to support this people sync.
PeopleDataEntityPrefix	String	“”	This is the prefix that will be used for your people sync data, this value must match the value set in your AppManager > Settings > AppSettings Manager - for "PeopleDataEntityPrefix" and "SearchIndexPrefix"
RootBlobContainer	String	“”	Remove if using Key Vault template defined above and BlobSoreContainer is set. This is the value set in AppManager's interchange.settings.config key "SettingsBlobContainerName"

Tenant Configuration

Tenant configuration is a set of required properties used to synchronize the source data such as AAD, OKTA, SharePoint User Profile Service, etc. Multiple tenants can be configured in an array. Custom Properties can be added to the tenant specific configuration. Example if a custom FetchOption, FetchProperties or AssemblyTypes “CustomFilterAssemblyType” is needed for the tenant, copy the configuration area (if it does not already exist) into the TenantConfiguration array item and customize it for the tenant.  In the table below an example of adding the FetchProperties is given.

FetchOptions

Global fetch options are used if Tenant specific fetch options are not configured. Include all FetchOptions at Tenant Specific, if you need to override any one of the fetch options then set at Global FetchOptions.

Option	Type	Default	Description
SyncUsers	Boolean	true	Synchronize configured user properties
SyncGroups	Boolean	true	Synchronize Active Directory Groups
SyncUsersAssignedToNoGroups	Boolean	true	Set to true, all users will be synced.  If the value is false, then users who are not assigned to any groups will be filtered out of the people sync.
SyncTags	Boolean	false	Set to true if Akumina Workspace Licensed and configured
SyncTypes	Boolean	false	Set to true  if Akumina Workspace License and configured
TrackUserGroupChange	Boolean	true	Enumerates the user changes for ActivityStream Access Control update
TrackUserPersonaChanges	Boolean	true	Enumerates the user changes for ActivityStream Access Control update
MergeGroupFieldsToUserGroup	Boolean	true	Duplicates the GroupFields into UserGroups entity
CollectMetrics	Boolean	true	Used only with Cosmos DB.  Stores all executed Request Units (RU) per execution. This fetch option is set at Global Fetch.

 

FetchProperties 

Global FetchProperties are used if Tenant specific FetchPropertiese are not configured. 

FetchProperties UserExtendedProperties field expansions 

Some properties are extendable, the following table summarizes the columns included in the UserExtendedProperties. 

UserExtendedProperties	Fields retrieved
Manager	Manager
AssignedLicenses	All Licenses and Count
AppRoleAssignments	id, principalDisplayName, principalId, principalType, resourceDisplayName, resourceId
DirectReports	displayName, givenName, surname, mobilePhone, businessPhones, jobTitle, mail, officelocation, preferredLanguage, userPrincipalName
OwnedDevices	deviceId, deviceMetadata, deviceVersion, operatingSystem, operatingSystemVersion, trustType, displayName
RegisteredDevices	deviceId, deviceMetadata, deviceVersion, operatingSystem, operatingSystemVersion, trustType, displayName
OtherProperties	All the other external properties configured in the AAD

 

EmailSettings 

Email settings are optional. When specified, the system will send email on sync status such as success or failure.

Property	Type	Default	Description
SmtpHost	String	“”	SMTP Host
SmtpPort	String	“”	SMTP Port
SmtpUser	String	“”	SMTP User
SmtpPassword	String	“”	SMTP Password
SendUsingAppManager	Boolean	false	If set to true, you do not need to specify other properties, it will call the configured AppManager endpoint to send emails.
NotifyFrom	String	“”	From Address
NotifyTo	String	“”	To Address

 

AssemblyTypes 

Global Assembly Types are used if Tenant specific Assembly Types are not set for the tenant.  Assembly Types let you configure your implementation of corresponding features such as Data Source, Storage, Queue, Custom Sync filter, etc.

 

Other People Sync Configuration Properties 

Property	Type	Default	Description
UsingSaaS	Boolean	false	Used to configure whether PeopleSync will support SaaS model (multi-tenancy). This is applicable only to Cosmos Db Storage Implementation  StoreInSingleContainerUsed to determine, whether Cosmos Db Storage should use Single Container, while using multi-tenancy model
StoreInSignleContainer	Boolean	true	Writes all Users, Groups, UserGroups and Persona into same entity with partition key of   Users: U-<TenantID>  Groups: G-<TenantID>  UserGroups: UG-<TenantID>  Persona: P-<TenantID>  Bookmark: B-<TenantID>
SingleContainerName	String	“users”	Storage Container name will be determined based on this value while using multi-tenancy model. If value not set, then PeopleDataEntityDataPrefix will be used as container name.
ResumeOnError	Boolean	true	Continue processing if any error occurs
ContinueOnSchedule	Boolean	false	Continue schedule is most commonly "false".  Most VM are using scheduled tasks and webjobs use triggered tasks instead of a "Continuous" running task.  However, this value is there to provide the option.  If  ContinueOnSchedule is "true" then the time schedule used is set below on key ScheduleIntervalInSeconds (described below).
ExistConsoleWhenDone	Boolean	true	If set to “true” then the console will close upon completion.  This should be left as true it is only changed to false for debug purposes.
ScheduleIntervalInSeconds	Number	60	If “ContinueOnSchedule” is set to “true” then a differential sync will occur every 60 seconds or whatever value desired and set for this key in seconds
QueueItemVisibilityTimeoutInMin	Number	30	If there are more than 5,000 users in Azure AD then this should be set to 30
MaxRetryAttempt	Number	3	The number of times the process will retry before erroring out.  This property combined with RetryDelayInMilliSeconds
SamplingCount	Number	10000	Total number of rows require to get the fields for generating the PersonaQueryFields.json and Generating the IndexColumns in Azure Search Service. Default value is 10000. If any missing column in Azure Search Service, increase the sampling count based on the requirement.
RetryDelayInMilliseconds	Number	3000	If throttling issue in the cloud, then the system will retry after given interval.  This property is combined with MaxRetryAttempt

 

FieldMappings 

In the people sync config folder there are 3 fieldsmapping.*.json files.  One is appropriate for people sync source from:

• Azure AD - fieldsmapping.aad.json
• Okta - fieldmapping.okta.json
• SharePoint User Profile (On premise) - fieldsmapping.sharepoint.json

Start with the appropriate people source file and then customize the file if needed.

 

 

Prefix: Set unique value to this field if you need to initialize prefix to fields, this is required to uniquify the fields if you sync cross multiple data sources.  PrefixExclude: System defined; you can add but cannot remove the default values  Group: For any customization of the Group fields.  Example in your AD you may have a group column called "id" (read in column) but in the Akumina framework you want id to really be objectId (write out to), then the field mapping will become “Id”:”objectId" Users: For any customization of the User fields, for example in your AD you may have a field called _firstname (reads in) but in the Akumina framework you want to have it represented as FirstName (write out to), then the field mapping will become “_firstname”:”FirstName”   UserGroups:  Same as “Users” but the property related to user groups  UserPreferences: Same as “Users” but the property related to user preferences  Note: Any value that starts with “~” is a constant. For example:  “~1033":“aklanguageid” : will be stored in our system column aklanguageid=”1033” for the site default language. 

Creating a custom fieldmapping file for a tenant

A custom fieldmapping file can be created to change things such as default languages or mappings.  Example fieldmapping.french.json or fieldmapping.*.json, where * is the unique name used for this tenant's ( * could be clientname) fieldmapping json file.  In the example below, start with the appropriate fieldmapping type file associated with your source data e.g. aad, okta or sharepoint. In the case where aad is the source,  copy fieldsmapping.aad.json and rename the file to be unique for your tenant in this example fieldmapping.French.json.  This tenant should have default language set to French.  Edit the file and change the language code from ~1033 to ~1036. example:

In the "Tenant Configuration" area of the config.json, set the FieldsMappingSource to this newly created file in the people sync directory example:

Running PeopleSync  

Generating Data Store 

Prerequisite: People sync requires .NET Core 8.0 or greater when running on a VM, visit https://dotnet.microsoft.com/download/dotnet-core/8.0 to downloads and install.

Go to PeopleSync directory, execute the following commands in the exact order.  It is important that the following steps must be completed entirely before continuing next commands.

• UserAndGroup.cmd
• DeQueue.cmd
• SyncUserPreference.cmd
• SyncPersonaSchema.cmd
• AddSearchIndex.cmd
• Persona.cmd

People sync running on VM - Configuring a scheduled task for the People sync and Personas

For incremental sync schedule, use the window task scheduler and configure a scheduled task to run:

• UserGroupAndQueue.cmd
• Persona.Cmd 

Running as WebJob 

If you are hosting the AppManager on a webapp, then you can run PeopleSync as a web job attached to the webapp or create a dedicated webapp just for PeopleSync.

 Triggered Mode 

Configure the PeopleSync for Triggered Run as described in the above sections

• Verify the appropriate config.json has the following keys set: 

  “ContinueOnSchedule”: false 

  “ExitConsoleWhenDone”: true 

•  re-zip the people sync folder.

Add the Triggered WebJob to your WebApp 

In Azure portal select your WebApp.

1. On 2^nd blade scroll down and select “WebJobs”
2. Select “+ADD”
3. Enter Name of WebJob
4. Click on folder icon and select the zipped-up people sync from your local computer
5. Set Type = Triggered
6. Set Tiggers = Scheduled
7. Set CRON Expression = 0 */1 * * * *  Note:  This is set to 1 minute, a client can determine how often to do a differential sync and set this as desired
8. Click OK

Best Practices 

1. For better performance remove the properties that are not required by your implementation.  For example, only enable the User Extended Properties if you need the information in the User Context to support site functionality. 
2. The more processors that your VM has the faster it will process the queue items.  For example, if you have 16 processors, then it will generate 16 threads of the process queue and process the items fast. Azure WebJobs will scale automatically to utilize all the available processes. 
3. If you are running on a VM and you have multiple VM’s you can copy the entire PeopleSync Directory to another VM and run startQueueSync.cmd at the same time. 

 

Miscellaneous

Azure Search 

Configuring Azure Search Services and acquiring the necessary key 

Setting up the Azure Search Service requires administrator permissions to the Azure Portal 

Access the Azure Portal. Click on “All Services” (left rail) and search for “Search Services” and select. 

• On the Search Service Blade click on “+Add” 
• URL – enter a URL (the value entered is your AzureSearchServiceName) – all lower case, example clientnameprodpeoplesearch 
• Subscription – Select the appropriate Subscription. 

• Resource group – Use existing – and select the appropriate resource group. 
• URL – enter a URL (the value entered is your AzureSearchServiceName) – all lower case, example clientnameprodpeoplesearch 
• Location – Set as the client preferred location, in my example West US 2 
• Pricing tier – based on number of users and indexes customer can choose anywhere from basic to standard. 

Acquiring the AzureSearchServiceApiKey 

On the Search service page, select the AzureSearchServiceName, in this example clientnameprodpeoplesearch. 

A set of blades will open. Select the navigation blade item “Keys” and copy the “PRIMARY ADMIN KEY” – this is the value need for the AzureSearchServiceApiKey. 

Configuring Okta application secret

This is for sample purposes only to show you how to configure Okta:

• Login as an Administrator for Okta Account using domain name.
• From Application home page, use “Admin” button to navigate to Admin Dashboard page
• Navigate “API” link in “Security” menu to land into “Token” page
• Click on “Create Token” button to initiate the token generation screen
• Enter any token name in the field and click “Create Token” button to generate token.
• New token will be generated and displayed in the screen. Copy this token for future reference.
• This token will expire in 30 days if it’s not used. Expiration will extend for next 30 days whenever we use it. Please make sure to configure the valid Token to run the sync.

Here's an example of Okta fields mapping: