Manage Lenovo System Update with Intune

This post will describe how you can manage Lenovo System Update on
Windows 10 devices with Intune.

Before you begin, you will need:
  • System Update Administrator Tools - This contains the System Update ADM/ADMX files. By default, the contents are extracted to C:\SWTOOLS\TOOLS\Admin
  • A Windows 10 device connected to Azure Active Directory and managed by Intune
  • System Update installed on the device

Ingest the TVSU ADMX file

  • Sign in to the Azure Device Management portal
  • Navigate to Device Configuration > Profiles > Click Create Profile
  • Enter the required information for the new profile, for example:
    • Name: Lenovo System Update configuration
    • Description: (Optional)
    • Platform: Windows 10 and later
    • Profile Type: Custom
  • In the Custom OMA-URI Settings menu, click Add and enter the following
    • Name: TVSU ADMX Ingest
    • Description: (Optional)
    • OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Lenovo/Policy/TVSU
    • Data Type: String
    • Value: Copy the contents of the tvsu.admx into this field
  • Click OK to complete adding the new OMA-URI row
  • Click Create to create the new profile
  • Assign the profile to a group.  This group should only include devices that have System Update installed.
Verify the settings have pushed to a device by launching Regedit and navigating to

HKLM\SOFTWARE\Microsoft\PolicyManager\AdmxDefault


Create a TVSU Policy

Example 1
  • Sign in to the Azure
    Device Management
    portal
  • Navigate to Device Configuration > Profiles >
    click the Lenovo System Update Configuration profile that was created earlier > Properties > Settings
  • In the Custom OMA-URI Settings menu, click Addand enter the following
    • Name: Admin Command Line
    • Description: Installs Critical and Recommended packages with a reboot type 3 (requires reboot)
    • OMA-URI:
      ./Device/Vendor/MSFT/Policy/Config/Lenovo~Policy~Cat_ThinkVantage_61~Cat_System_Update_63~Cat_UserSettings_74~Cat_General_78/Policy_Admin_CommandLine_154
    • Data Type: String
    • Value:
<enabled/>
<data id="Policy_TextBox_Element_Admin_CommandLine_155" value="/CM -search R -action INSTALL -includerebootpackages 3 -noicon -noreboot -nolicense -defaultupdate"/>

    • Click OK to complete adding the new OMA-URI row

Example 2

  • In the Custom OMA-URI Settings menu, click Addand enter the following
    • Name: Repository Path
    • Description: (Optional)
    • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Lenovo~Policy~Cat_ThinkVantage_61~Cat_System_Update_63~Cat_UserSettings_74~Cat_General_78/Policy_Repository_Location_116
    • Data Type: String
    • Value:
<enabled/>
<data id="Policy_TextBox_Element_Repository_Location_119" value="\\CustomRepoPath"/>
<data id="Policy_TextBox_Element_Repository_Location_120" value="\\CustomRepoPath2"/>
<data id="Policy_TextBox_Element_Repository_Location_121" value="\\CustomRepoPath3"/>

  • Click OK to complete adding the new OMA-URI row
  • Save the profile
Verify the policies have applied to the client by launching Regedit and navigate to

HKLM\SOFTWARE\Policies\Lenovo\System Update\UserSettings\General


Further Reading:

Enable ADMX-backed policies in MDM

Win32 and Desktop Bridge app policy

Comments

  1. Hi Phil,

    I have set up the profile in Intune and configured it. I can see the registry keys on the computer. However:
    1. When I run System Update it is asking me to provide a user name and password to connect to the local repo
    2. Do I need to change the \\CustomRepoPath settings to something more meaningful? ie a network or local path?
    3. It seems to be stuck at 49% Downloading package information: \\CustomRepoPath 3 (3 of 3)

    You also don't mention how the system update is initiated. Does it run automatically or is it manual?

    ReplyDelete
    Replies
    1. Hi, yes you'll need to replace the customrepopath to your actual repository, i.e. \\yourservername\lenovoupdates. If you only have one repository, you can remove the 2nd and 3rd paths.

      Delete
  2. Hi Phil,

    Thanks for this post.

    I have a question.

    1. Is this an all or nothing solution?
    (What I meant with that is this on the OMA URI is configured with install silent all critical or recommended. Is this possible to filter further? We like the idea of automatically but not all updates or updates like firmwares and bios update we want to do it in a more controllable situation)

    I found your other blog post about pushing individual drivers for an example through Win32 and it works well but our Lenovo device inventory is pretty big which makes it a pain to maintain.

    I appreciate any answers.

    Best regards,

    ReplyDelete
    Replies
    1. Hi, the reboot type of the package is what's important here. Reboot type 3 packages won't force the system to automatically reboot. However, reboot type 1 packages (BIOS, firmware) will generally either prompt the user for input and/or force reboot the system. If you have Update Retriever setup, you can check the details of each package for the reboot behavior. Hope this helps!

      Delete
    2. Hi,

      Thanks for the fast reply. I still wondering though if it's possible to further filter this with the OMA URI - I like the idea of not force the system to automatically reboot.

      But as I said earlier we are having users that might not know they are installing an update if this is handled automatically with OMA URI and that could basically brick their system board if they turn off or suspend the computer.

      What we are looking for is automatic updates through System Update but the most crucial onces like BIOS, Thunderbolt etc we want to do in a more controllable environment and with the OMA URI above it will just automatically install it if it's in the critical or recommended tab.

      So once again, is it possible to filter what it actually installs even further with OMA URI's? From my research it doesn't seems so and it's more like an all or nothing solution.

      Best regards,

      Delete
    3. Hi, there wouldn't be a way to filter any further. The reboot types that are set in the admincommandline is what the client will install. So yes, in a way, it is an all or nothing solution as you pointed out.

      However, if you do host a local update retriever repository where clients will connect to for updates, you could automate BIOS by changing the install switch. You can do this by modifying the package in UR and under the installation setup, replace the command line %PACKAGEPATH%\winuptp.exe -r to %PACKAGEPATH%\winuptp.exe -s, click apply, and the XML will be updated to silently install BIOS.

      Hope this helps

      Delete
    4. Thanks again for your reply. It helped immensely!

      Best regards,

      Delete

Post a Comment