Micro Update Service (MUS)

Introduction

The Micro Update Service (MUS) allows records (for example, Users, Applications, and Devices) to be updated by external processes (such as SCCM build scripts). It does this by reading micro update files from a shared location.

This approach enables business processes to update ManagementStudio without requiring any knowledge of the ManagementStudio API and with minimal rework.

The Micro Update Service Endpoint allows an external service to POST updates to MUS via a standard HTTP request. The external service must provide a valid access key, and only one access key can be active at a time. Update files are saved to disk and processed according to the normal MUS schedule.

TABLE OF CONTENTS

• Introduction
• Settings
• File Format
  • File Requirements
  • Filename Example
• Folder Monitoring Considerations
  • Example
• File Content Structure
  • Identifying the Target Record
  • Updating Fields
• MUS Endpoint Examples
  • Example 1 (Key in Url)
  • Example 2 (Key in Header)
• SCCM Command-Line Examples
  • Basic Example
  • Example Including Time in the Filename
• Updatable Modules
• Example Text files
• Security
  • Example

MUS Service requires MS version 2022.0.8.5 or higher
MUS Endpoint requires MS version 2026.16.1.1 or higher

Settings

• Enable MUS
  • Enables or disables the Micro Update Service from running.
• Schedule MUS
  • Sets one or more recurring scheduled times for the MUS service to process files.
• Run MUS Now
  • Manually starts the MUS service to process any files currently waiting.
• Current Run Start Time
  • Displays the date and time when the currently running MUS job started. If this field is blank, the job has completed.
• Monitor Folder 1, 2, 3
  • Specifies the local or UNC paths to monitor for new MUS files to process.
• MUS Endpoint Enabled
  • Enables or disables the Micro Update Service endpoint, which is used to submit MUS updates via HTTP POST.
• Access Key
  • Generates an access key that allows external services to post data to MUS anonymously via HTTP. Only one key can be active at a time. Generating a new key invalidates the previous one and may cause existing services to receive a 401 Unauthorised error until they are updated with the new key.
• Post Address
  • The URL used to submit MUS data via HTTP POST.
• Log
  • Recent log events for the MUS Service

File Format

The Micro Update Service (MUS) requires a correctly constructed text file to be placed in one of the folders monitored by the service.

File Requirements

The file must meet the following requirements:

• The filename must start with MUS_
• The filename should be unique (see note below)
• The file content must identify a ManagementStudio record
• The file content must identify at least one field or custom field ID
  • Multiple fields are supported, but each must be on its own line

Filename Example

• The filename MUS_DT113421_01.txt is valid because it:
• Starts with MUS_
• Includes an identifier (for example, a computer name)
• Ends with _01 to make this instance of the filename unique
  • A date/time value may also be used to ensure uniqueness

Note:

Unique filenames are not strictly required. However, processed files are stored for later inspection. If multiple files share the same filename, newer files will overwrite earlier versions.

Folder Monitoring Considerations

If multiple projects are running different instances of the Micro Update Service, each service must monitor a separate folder.

Example

\\ServerName\Share\ProjectName

\\DataServer01\Incoming\MergerProject

\\ServerName\Share\ProjectName

\\DataServer01\Incoming\HardwareRefreshProject

File Content Structure

Identifying the Target Record

The first line of the text file must identify the ManagementStudio object to be updated.

This line uses the ID prefix and must include:

• The target ID type
• The target name or value

Format:

ID:IdType:TargetName

Updating Fields

Each subsequent line updates a field or custom field.

Each update must be on its own line.

Format:

TargetType:Target:NewValue

MUS Endpoint Examples

Using PowerShell to send MUS Data to ManagementStudio

Example 1 (Key in Url)

$musUrl = "http://MS-Server/1/p/a/mus/fa6......"
$update = @'
ID:Hostname:PC00045
CFId:14801:True
CFId:14802:This is the error message from the task sequence
'@

Invoke-WebRequest -Uri $musUrl -Method Post -Body $update -ContentType 'text/plain; charset=utf-8'

Example 2 (Key in Header)

$musUrl = "http://MS-Server/1/p/a/mus"
$accessKey = 'fa6...'
$update = @'
ID : SamAccount : global\jdoe
Field: Email: jdoe@global.com
'@

Invoke-WebRequest -Uri $musUrl -Method Post -Body $update -ContentType 'text/plain; charset=utf-8' -Headers @{ accessKey = $accessKey }

Updatable Modules

Special Characters. ':' and 'new line' characters can't normally be used in the 'Value' portion of the micro update and need to be escaped.
To add a ':' use '\:' and to add a new line use '\n'.

When writing dates with MUS you need to escape the : in the time componant as 
CFID:999: 2024-05-09 02\:03

Example Text files

Ex - Update Devices from SCCM TS

ID:Hostname:PC00045

CFId:14801:True

CFId:14802:This is the error message from the task sequence

ID:MigrationID:8901

CFId:153:ThisData2`r`nThatData2`r`nMoreData8

Ex - Update a User 

ID : SamAccount : global\jdoe

Field: Email: jdoe@global.com

Ex - Create a new App and move it to a Process

Id: App-CustomerId: 12345

Option: CreateIfNotFound: true

Field: AppVendor: Adobe

Field: AppName: New Reader

Field: AppVersion:2021.011.20039

Process: 2. Discovery

Note: Note: Created from ServiceNow support ticket

Security

Because ManagementStudio reads anonymous text files from a shared location and uses them to update data, it is essential that the share is properly secured.

The share should be configured so that only approved Active Directory (AD) accounts have permission to write files to it. This ensures that only trusted processes can submit updates to ManagementStudio.

Example

If the Micro Update Service is used to process updates generated by an SCCM Task Sequence, then only the following accounts should have write access to the share:

• The SCCM Active Directory service account
• The ManagementStudio service account

All other users and accounts should be denied write access.

Further Support

If you require further support, please visit ManagementStudio's Service Desk to search the knowledge base or create a new support ticket.