Ilt LDSSM 1601.1 CG

Course Guide
Systems and Security

Administration Boot Camp
2016.3
ID# ILT-LDSSM-1601.1
This document is provided strictly as a guide. No guarantees can be provided or expected. This
document contains the confidential information and/or proprietary property of Ivanti, Inc. and its
affiliates (referred to collectively as “Ivanti”), and may not be disclosed or copied without prior
written consent of Ivanti.
Ivanti retains the right to make changes to this document or related product specifications and
descriptions, at any time, without notice. Ivanti makes no warranty for the use of this document and
assumes no responsibility for any errors that can appear in the document nor does it make a
commitment to update the information contained herein. For the most current product information,
please visit www.Ivanti.com.
© 2017, Ivanti, . All rights reserved. IVI-0001 1/17
Table of Contents
Table of Contents .............................................................................................................................................. 2
Management Suite 2016.3 Overview ............................................................................................................... 17
Module Objectives ....................................................................................................................................... 17
Introduction to Management Suite 2016 ....................................................................................................... 18
Management Suite 2016 .............................................................................................................................. 18
What Management Suite 2016 enables you to do ........................................................................................ 18
Where to go for more information ................................................................................................................. 19
Management Suite Terms ............................................................................................................................ 20
Ivanti Products ............................................................................................................................................. 20
Management Suite Core Server ...................................................................................................................... 21
Designing the Management Suite Domain ................................................................................................... 22
Planning the Organization Model ................................................................................................................. 22
Core Synchronization ................................................................................................................................... 22
Role Based Administration ........................................................................................................................... 23
Selecting components to implement............................................................................................................. 23
Understanding the different functionality available by device OS .............................................................. 23
Understand compatibility with previous versions of Management Suite .................................................... 23
Management Suite Environment .................................................................................................................. 24
Core Server ................................................................................................................................................. 24
Install / Upgrade to Management Suite 2016 ............................................................................................... 25
Other installation documents on the Ivanti Community Website................................................................ 26
Management Suite 2016.3 Installation Steps ............................................................................................... 26
Management Suite 2016.3 Upgrade Steps................................................................................................... 41
Systems and Security Administration Boot Camp 2016.3 2

Management Suite Customer Experience Improvement Program ................................................................ 47
Core Server Activation ................................................................................................................................. 48
Management Suite Console Types .............................................................................................................. 49
Core Server Console ................................................................................................................................ 49
Remote Console ....................................................................................................................................... 49
Web Console ............................................................................................................................................ 50
What Counts as a Managed Node ............................................................................................................ 50
Port Usage ............................................................................................................................................... 51
Core Database ............................................................................................................................................. 51
Core and Database Server Configurations ................................................................................................... 51
1-2000 Devices ........................................................................................................................................ 51
2,000+ Devices –Core Database on a Second Server .............................................................................. 51
Database Size .......................................................................................................................................... 52
Relational Database ..................................................................................................................................... 52
Unicode or Universal Database .................................................................................................................... 52
Changing the Database ............................................................................................................................ 52
Database Utilities ......................................................................................................................................... 53
CoreDbUtil.exe — Database Utility ........................................................................................................... 53
DbRepair — Database Repair Utility......................................................................................................... 53
Core Database Maintenance........................................................................................................................ 53
DBMS Maintenance.................................................................................................................................. 53
Management Suite Database Maintenance .............................................................................................. 54
Core Server Security .................................................................................................................................... 54
Public Key Infrastructure........................................................................................................................... 54
Sharing Keys among Core Servers .......................................................................................................... 55
Distributing Trusted Certificates to Devices .............................................................................................. 56
Client certificate model ............................................................................................................................. 57
Management Suite Shares and Directories .................................................................................................. 59
Federal Information Processing Standard 140-2 Mode ................................................................................ 60
Steps to Enable FIPS 140-2 ..................................................................................................................... 61
Core Auditing ............................................................................................................................................... 62
Core Auditing Rights and Roles ................................................................................................................ 62
Suggested Auditing Guidelines ................................................................................................................. 63
Core Server Check for Understanding ......................................................................................................... 65
Consoles ......................................................................................................................................................... 66

Console Overview ........................................................................................................................................ 67
Consoles ...................................................................................................................................................... 67
Core Server Console ................................................................................................................................ 67
Remote Console ....................................................................................................................................... 67
Web Console ............................................................................................................................................ 68
Single Sign-on into the Console ................................................................................................................... 68
Management Suite Console Navigation Basics ............................................................................................ 70
Tool Menu ................................................................................................................................................ 70
Toolbar ..................................................................................................................................................... 70
Core Server Menu .................................................................................................................................... 71
Toolbox Menu ........................................................................................................................................... 71
Tools ........................................................................................................................................................ 71
Tool Groups.............................................................................................................................................. 71
Network View ........................................................................................................................................... 71
Layout Menu............................................................................................................................................. 74
Themes .................................................................................................................................................... 74
Find .......................................................................................................................................................... 74
Inventory List ............................................................................................................................................ 75
Component Window ................................................................................................................................. 75
Tool Tabs ................................................................................................................................................. 75
Console Grouping ........................................................................................................................................ 75
Console Setup Wizards................................................................................................................................ 76
Getting Started Wizard ............................................................................................................................. 76
Discovering and Installing Agents Wizard ................................................................................................. 76
Mobile Device Management Wizard ......................................................................................................... 76
User Management Wizard ........................................................................................................................ 76
Security Updates wizard ........................................................................................................................... 77
Launch the Console (Admin Console or Remote Console) .......................................................................... 77
About the Login Dialog ............................................................................................................................. 77
Fast Views ................................................................................................................................................... 78
Configure the Network View with Column Sets ............................................................................................ 78
Column Sets Tool ..................................................................................................................................... 78
About the Agent Status Options Dialog..................................................................................................... 78
Web Console Navigation Basics .................................................................................................................. 79

Configuring Role-Based Administration ........................................................................................................ 80
Role-Based Administration Overview........................................................................................................ 80
Role-Based Administration Workflow ........................................................................................................ 81
Adding Management Suite Console Users ............................................................................................... 81
Managing Authentications ........................................................................................................................ 83
Managing Roles ....................................................................................................................................... 85
Understanding Rights ............................................................................................................................... 86
Creating Scopes ....................................................................................................................................... 87
Using Teams ............................................................................................................................................ 89
Scheduled Tasks ......................................................................................................................................... 91
Active Directory Targeting ............................................................................................................................ 92
Diagnostics .................................................................................................................................................. 92
Diagnostics Toolbar .................................................................................................................................. 93
IPv6 Communication .................................................................................................................................... 95
Credant™ Integration ................................................................................................................................... 96
Credant Architecture................................................................................................................................. 96
Management Suite Integration with Credant ............................................................................................. 96
Consoles Check for Understanding .............................................................................................................. 98
Agents ............................................................................................................................................................. 99
Agents Overview ........................................................................................................................................... 100
Supported Managed Devices in Management Suite version 2016.............................................................. 100
Client-Side Certificates............................................................................................................................... 100
Architecture ............................................................................................................................................ 100
Enhanced Macintosh™ Support ................................................................................................................. 105
Virtual Desktop Interface Support .............................................................................................................. 106
Legacy Agent Support: Deploying agents to Windows XP/98/95/NT devices ............................................. 108
Agent configuration in mixed-language environments ................................................................................ 108
Creating a Managed Device ....................................................................................................................... 108
Discovery ................................................................................................................................................... 108
Unmanaged Device Discovery................................................................................................................ 108
UDD Rights ................................................................................................................................................ 111
UDD Limits................................................................................................................................................. 111
eXtended Device Discovery ....................................................................................................................... 111
Self-Electing Subnet Services .................................................................................................................... 111

Client Self-Election Process ....................................................................................................................... 112
Client Self-Election Process Architecture ................................................................................................... 112
Listener Technology and Actions ............................................................................................................ 112
Self-Electing Subnet Services Offered .................................................................................................... 113
Steps to Enable Self-Electing Subnet Services....................................................................................... 113
Configure Self-elected Subnet Services ................................................................................................. 113
Create the Client Connectivity Settings................................................................................................... 114
Deploy a Client Connectivity Agent Setting to a Managed Device .......................................................... 117
Enable or disable subnet services as desired ......................................................................................... 118
Self-Election Process ............................................................................................................................. 118
Self-Election Database Architecture ....................................................................................................... 118
The Agent Settings Tool............................................................................................................................. 118
Agent Configurations.................................................................................................................................. 135
Agent Configuration Tool ........................................................................................................................ 135
Agent Configuration Components ........................................................................................................... 136
Create an Agent Configuration ................................................................................................................... 137
To create an agent configuration ................................................................................................................ 137
Creating a Windows Agent Configuration ............................................................................................... 137
To Push an Agent Configuration to devices ............................................................................................... 140
Federal Information Processing Standard 140-2 Mode ........................................................................... 140
Using the Advance Agent ........................................................................................................................... 142
To create an advance agent configuration .............................................................................................. 144
To set up an advance agent push distribution......................................................................................... 144
Pulling the Management Suite Agent from the Core Server ....................................................................... 145
Scheduling Deployment of the Management Suite Agent ........................................................................... 145
Create standalone Agent Configuration packages ..................................................................................... 145
Uninstalling Device Agents......................................................................................................................... 146
Update Agent settings on Managed Devices .............................................................................................. 146
Mobility Management ................................................................................................................................. 146
Setup ...................................................................................................................................................... 146
Mobile Devices Supported ...................................................................................................................... 147
Mobility settings ...................................................................................................................................... 147
Software Packages for Mobile Devices ................................................................................................... 147
Inventory for Mobile Devices .................................................................................................................. 147
Configuring Macintosh Agents ................................................................................................................... 147

Configuring Linux and UNIX device Agents................................................................................................ 148
Agent Health .............................................................................................................................................. 148
Agent Health Technology ....................................................................................................................... 148
Steps to Enable Agent Health ................................................................................................................. 148
Agent Health Additional Information ....................................................................................................... 154
Agent Watcher ........................................................................................................................................... 154
Troubleshooting the Agent Installation ....................................................................................................... 156
Management Suite Agents Check for Understanding ................................................................................. 157
Remote Control ............................................................................................................................................. 158
Module Objectives ..................................................................................................................................... 158
Solutions Management Remote Control Provides ...................................................................................... 159
Remote Control Security for Console Users ............................................................................................... 159
Remote Control Architecture ...................................................................................................................... 160
Remote Control Session Requirements .................................................................................................. 160
HTML 5 Remote Control ............................................................................................................................ 161
Using HTML 5 Remote Control from a Mobile Device ............................................................................. 166
Remote Control Settings ............................................................................................................................ 166
Remote Control Legacy Version Implementation ....................................................................................... 174
Starting a Legacy Remote Control session from a Console .................................................................... 174
Starting a Legacy Remote Control session from a Web Console ............................................................ 174
Legacy Remote Control Viewer Options ................................................................................................. 175
Optimize performance tab in Options...................................................................................................... 178
Remote Control Viewer Commands ........................................................................................................... 179
Using Remote Control with a Cloud Services Appliance ............................................................................ 180
Initiating a Remote Control session using a CSA .................................................................................... 181
Federal Information Processing Standard 140-2 Mode ........................................................................... 182
Remote Control Reporting ......................................................................................................................... 183
Remote Control Logging ......................................................................................................................... 183
Remote Control Reports ......................................................................................................................... 183
Check for Understanding Concerning Management Suite Remote Control ................................................ 187
Inventory ....................................................................................................................................................... 188
Module Objectives: .................................................................................................................................... 188
Inventory Solution ...................................................................................................................................... 189
New Inventory Features in Version 2016.................................................................................................... 189
Post to Web Service ............................................................................................................................... 189

Inventory Service Multiple Server Support .............................................................................................. 190
Inventory Service Self-Monitoring (Degradation Monitoring) ................................................................... 190
Max Scan File Size ................................................................................................................................. 191
Inventory Scanner Updates .................................................................................................................... 191
Inventory Scanning Process....................................................................................................................... 196
Delta Scan Features .................................................................................................................................. 197
How the Delta Scan Works ..................................................................................................................... 197
Delta Scanning Synchronization ............................................................................................................. 197
Device ID ................................................................................................................................................... 197
Inventory Scan Types ................................................................................................................................ 198
Inventory Scanner Switches ....................................................................................................................... 198
Running the Inventory Scanner .................................................................................................................. 199
Inventory settings in Agent Settings ........................................................................................................... 200
Inventory Settings: ................................................................................................................................ 202
Inventory Settings in the Local Scheduler .................................................................................................. 208
Real-Time Inventory and Monitoring .......................................................................................................... 209
Real-time Inventory and Monitoring includes: ......................................................................................... 210
Automated Software Discovery .................................................................................................................. 213
Configuring the Inventory Service .............................................................................................................. 214
General Tab ........................................................................................................................................... 214
Inventory Tab ......................................................................................................................................... 216
LDAPPL3 files ............................................................................................................................................ 221
Non-Persistent Virtual Desktops and SOFTMON.EXE ............................................................................... 222
Manage Software List ................................................................................................................................ 223
Capture Registry Information and add it to Inventory .............................................................................. 224
Capture Custom WMI Data and add it to Inventory ................................................................................. 225
Adding Software to be Scanned ............................................................................................................. 226
Monitoring URL Items ............................................................................................................................. 227
Settings .................................................................................................................................................. 228
Custom Data Forms ................................................................................................................................... 229
Sending Forms to Managed Devices ...................................................................................................... 229
Launching Forms .................................................................................................................................... 230
Process .................................................................................................................................................. 231
Resources for Inventory ............................................................................................................................. 231
Inventory on MAC devices ......................................................................................................................... 231

Queries ...................................................................................................................................................... 231
Query Operators ..................................................................................................................................... 232
Troubleshooting Inventory Issues:.............................................................................................................. 234
LANDESK Inventory Server service Logging .......................................................................................... 234
Check for Understanding concerning Inventory .......................................................................................... 236
Inspector ....................................................................................................................................................... 237
Inspector Use Case ................................................................................................................................... 238
Utilizing Inspector....................................................................................................................................... 238
Inspector for Managed Devices .................................................................................................................. 238
Inspector for Managed Devices - Properties Tab .................................................................................... 239
Inspector for Managed Devices - Processes Tab ................................................................................... 240
Inspector for Managed Devices - Services Tab ...................................................................................... 241
Inspector for Managed Devices – LD Download Tab .............................................................................. 242
Inspector for Managed Devices - Users Tab ........................................................................................... 242
Inspector for Managed Devices - Tasks Tab........................................................................................... 242
Inspector for Managed Devices - PCI compliance Tab ........................................................................... 242
Inspector for the Core Server ..................................................................................................................... 242
Core Server Inspector - Devices Tab ...................................................................................................... 243
Core Server Inspector – Software Licenses ............................................................................................ 244
Core Server Inspector – Distribution ....................................................................................................... 245
Core Server Inspector – RBA ................................................................................................................. 245
Core Server Inspector – Licensing .......................................................................................................... 246
Core Server Inspector – Security ............................................................................................................ 247
Core Server Inspector – Health .............................................................................................................. 248
Inspector for the Scheduled Tasks ......................................................................................................... 249
Inspector for Vulnerabilities .................................................................................................................... 250
Inspector for Queries .............................................................................................................................. 252
Adding pictures of users to the Inspector ................................................................................................... 252
Creating Custom Inspectors ....................................................................................................................... 253
Management Suite Reporting ........................................................................................................................ 255
Overview of Reporting................................................................................................................................ 256
Dashboards ............................................................................................................................................... 256
Charts ........................................................................................................................................................ 257

Workspaces ............................................................................................................................................... 257
Task Overview ........................................................................................................................................ 259
Asset Manager – Software Optimization ................................................................................................. 260
Expiring Hardware .................................................................................................................................. 261
Software Licenses .................................................................................................................................. 262
Security Manager – Security Dashboard ................................................................................................ 263
Self Service - Software Catalog .............................................................................................................. 264
Self Service - Launchpad........................................................................................................................ 265
Self Service - Document ......................................................................................................................... 266
Administration – Manage Users .............................................................................................................. 267
Administration – Dashboard Designer .................................................................................................... 268
Administration – Connectors................................................................................................................... 269
Administration – Theming ....................................................................................................................... 270
Reporting in Management Suite ................................................................................................................. 270
Reporting formats: .................................................................................................................................. 270
Launching the Reporting Tool ................................................................................................................. 271
Types of reports available: ......................................................................................................................... 271
One-click Reports ................................................................................................................................... 271
Standard (predefined) Reports ............................................................................................................... 272
New Custom Report ............................................................................................................................... 273
Report groups......................................................................................................................................... 274
Report Properties ................................................................................................................................... 275
The Report Viewer ..................................................................................................................................... 275
The Report Designer .................................................................................................................................. 276
Using the Report Designer ..................................................................................................................... 277
For Additional report resources .................................................................................................................. 280
Check for Understanding concerning Reporting ......................................................................................... 280
Software License Monitoring ......................................................................................................................... 281
Use Case ................................................................................................................................................... 282
Features and Functionality ......................................................................................................................... 282
Architecture................................................................................................................................................ 283
Agent Configuration for Software License Monitoring ................................................................................. 283
Role-Based Administration for Software License Monitoring ...................................................................... 284
Navigating the Software License Monitoring Tool....................................................................................... 285

Steps to Implement Software License Monitoring ....................................................................................... 289
Normalize the Vendor ............................................................................................................................. 289
Set products to Monitor .......................................................................................................................... 290
Add Licenses .......................................................................................................................................... 291
Set up Allocation (optional) ..................................................................................................................... 291
Set up Reclamation (optional) ................................................................................................................ 291
Reports................................................................................................................................................... 293
Software License Monitoring and Ivanti Data Analytics ........................................................................... 294
Adding Software Licenses Manually ....................................................................................................... 295
Software License Monitoring Files (for Troubleshooting) ............................................................................ 296
Check for Understanding about Software License Monitoring .................................................................... 297
Software Distribution ..................................................................................................................................... 298
Software Distribution Overview .................................................................................................................. 299
Software Distribution Components ............................................................................................................. 299
Vendor Software Package ...................................................................................................................... 300
Management Suite Distribution Package ................................................................................................ 301
Distribution and Patch Agent Setting ...................................................................................................... 301
Scheduled Task ...................................................................................................................................... 302
Software Source ..................................................................................................................................... 302
Software Distribution Architecture .............................................................................................................. 302
Scheduled Task settings ............................................................................................................................ 303
Software Distribution Download Hierarchy ................................................................................................. 305
Software Distribution Push ..................................................................................................................... 308
Software Distribution Policy .................................................................................................................... 308
Preferred Servers ....................................................................................................................................... 310
Content Replication .................................................................................................................................... 310
Self-Organizing Multicast™ ........................................................................................................................ 311
Self-Organizing Multicast Behavior ......................................................................................................... 312
Multicast Settings (Pre-9.6 Agents Only) ................................................................................................ 312
Backup / Restore Software Distribution Packages .................................................................................. 315
UNC Shares ........................................................................................................................................... 315
Web Shares............................................................................................................................................ 316
Software Distribution Package Types ..................................................................................................... 316
Distribution Packages Menu....................................................................................................................... 316

Creating Management Suite Distribution Packages ................................................................................... 321
Metadata ................................................................................................................................................ 322
Creating Software Distribution Packages................................................................................................ 326
Agent Settings............................................................................................................................................ 332
Scheduling the Distribution Package .......................................................................................................... 340
Default Scheduled Task Settings ............................................................................................................... 346
Software Distribution on the Managed Device ............................................................................................ 349
Software Distribution Client .................................................................................................................... 349
Portal Manager Settings ......................................................................................................................... 351
Portal on the Managed Device ................................................................................................................... 352
Launchpad ............................................................................................................................................. 353
Task History ........................................................................................................................................... 354
Launchpad Architecture .......................................................................................................................... 354
Reporting in Software Distribution .............................................................................................................. 355
Rollout Projects in Software Distribution .................................................................................................... 355
Software Distribution Use Case .............................................................................................................. 355
Implementation .......................................................................................................................................... 356
Project Step Properties for a Software Distribution Project Rollout ............................................................. 356
Action history .......................................................................................................................................... 358
Application Builder ..................................................................................................................................... 359
Troubleshooting Software Distribution ........................................................................................................ 360
Gathering Server Side and Client Side Log Files ....................................................................................... 360
Check for Understanding concerning Software Distribution ........................................................................ 361
Operating System Provisioning...................................................................................................................... 362
Operating System Provisioning Use Cases ................................................................................................... 363
What is Operating System Provisioning ..................................................................................................... 363
Features offered in Operating System Provisioning ................................................................................... 363
Support for many imaging tools .................................................................................................................. 364
Sector vs File Based Imaging ................................................................................................................. 365
UEFI and BIOS support ............................................................................................................................. 365
WinPE ........................................................................................................................................................ 365
Sysprep...................................................................................................................................................... 365
Provisioning Tool and Toolbox Selection.................................................................................................... 365
Agent-Based and PXE-based OS Provisioning .......................................................................................... 366

How PXE fits into the DHCP process...................................................................................................... 366
PXE Representatives ................................................................................................................................. 366
Changes in Version 2016.3 for PXE Representatives ............................................................................. 366
PXE Service Self-Election Process......................................................................................................... 367
Designating the PXE Representative ...................................................................................................... 367
PXE Service Settings ............................................................................................................................. 367
PXE Boot Options................................................................................................................................... 369
Troubleshooting PXE Representatives ................................................................................................... 369
Preferred Servers ....................................................................................................................................... 370
Content Replication ................................................................................................................................ 370
Mac Provisioning ........................................................................................................................................ 371
Provisioning Agent-Based Architecture ...................................................................................................... 371
Provisioning Agent Plugins ..................................................................................................................... 372
Provisioning Bare-Metal Devices ............................................................................................................... 372
Provisioning Workflow ................................................................................................................................ 373
Vboot Workflow ...................................................................................................................................... 373
PXE Workflow ........................................................................................................................................ 374
Provisioning in Detail .............................................................................................................................. 374
Windows 10 Boot.wim ................................................................................................................................ 375
Steps to Utilize Operating System Provisioning .......................................................................................... 375
Step 1 – Create a Template.................................................................................................................... 375
Step 2 – Configure the Template ............................................................................................................ 375
Step 3 – Invoke the OS Provisioning Template ....................................................................................... 375
Scheduled Task ...................................................................................................................................... 376
Use Case for Scheduling an OS Provisioning Template ......................................................................... 376
Operating System Provisioning Rights ....................................................................................................... 376
Creating Templates .................................................................................................................................... 377
Template Sections ..................................................................................................................................... 377
Provisioning Actions ............................................................................................................................... 378
Conditional (If . . . Else) Branching ............................................................................................................. 397
Machine Mapping ....................................................................................................................................... 397
Manage Drivers to the Windows PE Image ................................................................................................ 398
Branding .................................................................................................................................................... 400
Product Mapping Customization ................................................................................................................ 401
Changing Wallpaper in WinPE ................................................................................................................... 402

Create Provisioning Boot Media ................................................................................................................. 402
Hardware Independent Imaging ................................................................................................................. 403
How Hardware Independent Imaging Works........................................................................................... 404
Steps to Implement Hardware Independent Imaging .............................................................................. 405
Managing Drivers in the HII Driver Repository ........................................................................................ 406
Provisioning Settings.................................................................................................................................. 407
Branding .................................................................................................................................................... 408
Self-Organizing Multicast™ ........................................................................................................................ 409
Targeted Multicast Behavior ................................................................................................................... 409
Identifiers and Imaging ............................................................................................................................... 410
OS Provisioning Variables ......................................................................................................................... 410
Device Variables .................................................................................................................................... 410
Public Variables ...................................................................................................................................... 411
Template Variables................................................................................................................................. 412
Action Variables ..................................................................................................................................... 413
Device Naming........................................................................................................................................... 414
Includes .................................................................................................................................................. 417
Included by ............................................................................................................................................. 417
Properties ............................................................................................................................................... 418
History .................................................................................................................................................... 418
XML ........................................................................................................................................................ 419
Options ................................................................................................................................................... 420
Operating System Provisioning Toolbar Options ........................................................................................ 421
Delete ..................................................................................................................................................... 421
Refresh................................................................................................................................................... 421
Create a Template Group ....................................................................................................................... 421
Schedule Template................................................................................................................................. 421
Import Templates.................................................................................................................................... 422
Help ........................................................................................................................................................ 422
OS Provisioning Template Options ............................................................................................................ 422
Provisioning Alerting Ruleset ..................................................................................................................... 423
Mac Provisioning ........................................................................................................................................ 424
Setup NetBoot on an OS X Server ......................................................................................................... 424
Mac Provisioning Actions........................................................................................................................ 425
Troubleshooting ......................................................................................................................................... 429

Gathering Server Side and Client Side Log Files ....................................................................................... 429
Check for Understanding concerning Provisioning ..................................................................................... 430
Patch Management ....................................................................................................................................... 431
Patch Management Use Case Scenario..................................................................................................... 432
Steps to Implementing Patch Management ................................................................................................ 432
Downloadable Content from Subscription Servers ..................................................................................... 432
Types ..................................................................................................................................................... 432
Key Features of Download Content Types ............................................................................................. 432
Architecture................................................................................................................................................ 435
Step 1: Download Definitions .................................................................................................................. 435
Step 2: Disable replaced rules ................................................................................................................ 439
Step 3: Determine Definitions to be scanned .......................................................................................... 441
Step 4: Create a Distribution and Patch Agent setting to use during a Patch scan ................................. 443
Distribution and Patch settings ............................................................................................................... 445
Step 5: Scan managed devices to determine existing vulnerabilities ...................................................... 448
Step 6: Viewing the Vulnerabilities which need Remediation .................................................................. 449
Step 7: Downloading Remediations for Vulnerabilities ............................................................................ 450
Step 8: Deploying Remediations............................................................................................................. 451
Minimizing bandwidth consumption ........................................................................................................ 451
Self-Organizing Multicast ........................................................................................................................ 451
Targeted Multicast Behavior ................................................................................................................... 451
Deploying the remediation Patches ........................................................................................................ 452
Step 9: Run Reports showing Vulnerability Status .................................................................................. 455
Step 10: Repeat as needed .................................................................................................................... 455
Toolbar options in the Patch and Compliance Tools .................................................................................. 455
Type (Downloadable Content Types)...................................................................................................... 455
Select a scope ........................................................................................................................................ 455
Filter ....................................................................................................................................................... 456
Download updates .................................................................................................................................. 456
Create a task .......................................................................................................................................... 456
Configure settings................................................................................................................................... 457
Display dashboard in a separate window ................................................................................................ 458
Import definitions .................................................................................................................................... 458
Export selected custom definitions ......................................................................................................... 458

Scan information .................................................................................................................................... 458
Computers out of compliance ................................................................................................................. 459
Refresh................................................................................................................................................... 459
Create custom definition ......................................................................................................................... 459
Properties ............................................................................................................................................... 460
Delete selected items ............................................................................................................................. 460
Purge patch and compliance definitions (administrator only) .................................................................. 460
Disable replaced rules ............................................................................................................................ 460
Help ........................................................................................................................................................ 461
Utilizing a Rollout Project to Automate Patch Deployment ......................................................................... 461
Patch Management Use Case ................................................................................................................ 461
Implementation ....................................................................................................................................... 462
Project Step Properties for a Patch Management Project Rollout ........................................................... 462
Action history .......................................................................................................................................... 464
Rollout Project Properties ....................................................................................................................... 464
Rollout Projects Toolbar ......................................................................................................................... 466
Check for Understanding of Patch Management ........................................................................................ 467
Ivanti Cloud Services Appliance .................................................................................................................... 468
Solutions provided by the Ivanti Cloud Services Appliance (Powered by Landesk) .................................... 469
What is the Cloud Services Appliance ........................................................................................................ 470
Cloud Services Appliance Security ......................................................................................................... 471
Notable Features of the Cloud Services Appliance .................................................................................... 472
Placement of the Cloud Services Appliance ............................................................................................... 472
Configuring the Cloud Services Appliance ................................................................................................. 474
Steps to configure the Cloud Services Appliance ................................................................................... 475
Check for Understanding of the Cloud Services Appliance......................................................................... 478

Management Suite 2016.3 Overview
Module Objectives
- Outline Solutions Management Suite Provides
- Demonstrate Where to go for Information Regarding Management Suite
- Define Management Suite Terms and Definitions
- Recognize Other Products, Solutions, and Services, Ivanti Offers

Introduction to Management Suite 2016
Ivanti Management Suite (powered by Landesk) is a collection of tools that help manage Windows, Macintosh,
Linux, UNIX, and mobile devices. Use these tools to remote control managed devices, manage inventories of
hardware and software, distribute software packages, monitor software usage, deploy Operating System
images, detect and remediate security risks, and complete many other management tasks.
Management Suite 2016

This course includes new features from both the 2016.1 (also called version 10.0) and 2016.3 (also called
version 10.1).
What Management Suite 2016 enables you to do

Management Suite allows you to perform a superabundance of management tasks on managed devices in
your enterprise.
There are three (3) steps to take a device from unmanaged to managed:
1. Discover devices in the enterprise to be managed
2. Deploy the Management Suite agent

3. Receive an inventory scan from the managed device
Scans received from a managed device are added to a database, which in turn makes the device appear in a
Management Console. Now that the device is managed and available to an administrator the numerous
management tasks can be performed on the managed device.
The following tools are available in Management Suite:
 Discovery: The first step in finding devices in the domain. Discovery can be done actively, via a ping
sweep, or passively, by implementing a subnet listener.
 Agent Deployment: Placing the management software on the device provides the ability to perform
numerous management tasks on the device.
 Inventory: Hardware and Software scan is performed on the managed device providing ability to manage
inventories, track inventory changes, and create forms to gather custom data from devices, for the
managed devices in your enterprise.
 Software Distribution: Quickly distribute software via push or policy to managed devices throughout your
enterprise. The distribution of software can be initiated via Push from the core, or pulled via Policy from the
Managed Device.
 Reporting & Dashboard: Create and manage queries, as well as view and export reports on inventory
data of managed devices in your enterprise. View charts and graphs to quickly ascertain trends concerning
managed devices throughout the enterprise.
 Software License Monitoring: Monitor software usage, show license compliance, and track software
usage trends.
 Cloud Services Appliance (separate purchase): Manage Devices, anywhere in the world, from anywhere
in the world, by the device simply connecting to the internet.
 Mobility Management: iPhone*, Android*, and Chromebook* mobile devices.
 OS Provisioning & Migration: Deploy and Provision Operating System (OS) images, migrate user
profiles, and migrate software packages.
 Remote Control: Diagnose and troubleshoot problems on remote devices from the console, as if you were
there in person. You can remote control, reboot, execute files, transfer files to devices, and other things, to
resolve issues.
 Power Management: Manage Power consumption of managed devices by placing policies on managed
devices.
 Patch Management: Manage Operating System and Application Patches on managed devices.
Where to go for more information

The Ivanti User Community at http://community.ivanti.com has user forums, best known methods, and
recorded e-learning sessions for configuring and implementing Management Suite features and tools. Also, the
community Web site is your main resource for Management Suite installation and deployment information,
such as:
 System requirements for running Management Suite
 Installing Management Suite
 Activating the core server
 Ports used by Management Suite
 Upgrading from previous versions of Management Suite
The Ivanti Help Center at http://help.ivanti.com has Ivanti Product Documentation and online help.

Management Suite Terms
The following are terms used throughout this training manual. Familiarize yourself with these terms before
continuing:
Core Server: The physical server where Management Suite is installed.
Database Management System (DBMS): The database created by the Management Suite installation. This
database is normally installed on the Core Server managing less than 2000 nodes. Alternatively, if managing
more than 2000 nodes, the database is installed on a server other than the Core Server.
Management Suite Console: The Console installed on the Core Server by default. This Console can
optionally be installed on other managed devices.
Web Console: The browser-based counterpart to the Management Suite Console. The Web Console can only
be accessed by accessing a browser like Internet Explorer and typing “http:// <CoreServerName>/remote/”
into the Address field and pressing Enter.
Managed Machine/Device/Node/PC: A PC that has had the Management Suite agents installed to it, and
whose record exists in the inventory database.
Rollup Core Server and Database: A Server and database that contain a combination of inventory from
multiple Core Servers. This is mainly to report on all managed nodes in an enterprise.
Ivanti Products
Ivanti offers a variety of products, solutions, and services, to answer a superabundance of business needs. To
see a complete list of products, solutions offered, and the services rendered, please visit http://www.ivanti.com.

Management Suite Core Server
Module Objectives
In this Core Server section, you will:
 Prepare a design for the Management Suite Domain

 Outline how to plan the Organization Model
 Demonstrate how to configure Core Synchronization
 Setup and Utilize Role-Based Administration
 Select components to Implement
 Outline the Management Suite Environment
 Identify how to install the Core Server
 Outline the Core Server Prerequisites
 Demonstrate how to use the Management Suite Console
 Activate the Core Server
 Describe the Management Suite Database Functionality
 Identify and implement security on the Core Server
 Describe how Management Suite implements Public Key Infrastructure
 Describe how Management Suite implements Client Certificates
 Identify key Management Suite shares and directories
 Enable Core Auditing

Designing the Management Suite Domain
Although the course does not include a highly detailed installation design process, it is still important to
understand the steps that go into the implementation of Management Suite. Because of the complexity of
installing a system such as this, it is important to consider several things and gather specific information about
the environment prior to starting the implementation process.
The following information should be gathered prior to starting the implementation process:
 Determine the number of sites where devices will be managed
 Estimate the number of devices to be managed at each location
 Select the location for the Core Server(s), Consoles, and Preferred Servers
 Plan placement of the program files for the Core Server(s)
 Select database placement location (one per Core Server, and Rollup Core)
 Identify the domains with managed devices
 Understand the functionality available for each device OS
Planning the Organization Model

Before the implementation takes place, an organization model must be planned. With the powerful servers
available today, one single Core Server can manage over 100,000 devices. Even with no physical need to
have separate Core Servers, some organizations choose to have separate Core Servers due to organizational
structuring, or to accommodate networks which must remain separate. If there are multiple Core Servers with
production data, a Rollup Core Server and database accommodates having one central database for reporting
purposes.
In any case, it is recommended that a test Core Server be implemented to assure settings yield desired results,
and that software distribution, patch, imaging, and other management tasks, first take place on non-production
devices before efficiently implementing changes throughout the enterprise.
Core Synchronization
For organizations which have multiple Core Servers (for geographic, hierarchal, organizational, or other
reasons). Core synchronization provides the ability to take meticulously and methodically created settings and
configurations on a Core Server and propagates them to one or more Core Servers, with minimal effort. In
Change Management implementations (using ITIL or Six Sigma), a test Core Server could synchronize
configurations and settings to the production Core Server.
Core synchronization can be set for the following items:
 Agent Configurations
 Agent Settings
 Alerting
 Delivery Methods
 Distribution Packages
 Power Management Settings
 Query/Column Sets
 Reports
 User Management
 Scripts
 Tasks and Policies
The document “Best Known Methods for Core Synchronization” can be downloaded at:
http://community.ivanti.com/support/docs/DOC-7402.

Role Based Administration
Management Suite is versatile enough to allow users to manage the entire enterprise or limited portions based
upon geography, hierarchy, or other logical divisions. Scopes allow Management Suite Administrators the
ability to grant or limit what Managed Devices a Console User can access. Rights allow or limit what each
Console User may do to act upon the Managed Devices allowed via scope assignment. There is no need to
create multiple Core Servers to limit what Console Users can access and act upon. Role-Based Administration
provides the capability to manage Console Users, roles, and scopes.
Selecting components to implement

Management Suite offers the flexibility to activate only the desired tools as a part of the agent. The Standard
Management Suite Agent contains the baseline functionality components of every Management Suite agent,
and is installed by default. Software Distribution is also installed by default. In addition, several components
can be included in the agent configuration, each with specific functionalities. Determining which components to
include in the Management Suite Agent configuration depends on which functionality is desired on the
Managed Device. Numerous agent configurations can be created to provide different levels of functionality
across the enterprise. A list of agent components and agent settings can be selected as a part of the agent to
be installed. The following is a list of the available component agents:
 Standard Management Suite agent
 Custom data forms
 Remote control
 Power management
 Software Distribution
 Ivanti Antivirus (separate purchase)
 Ivanti Endpoint Security (separate purchase)
 Real-time Inventory and Monitoring Baseline components
 Real-time Inventory and Monitoring Extended components
 Workspaces
 Agent Watcher
Understanding the different functionality available by device OS
Management Suite offers different levels of support for the various supported operating systems. For example,
Inventory scanning is supported on Windows, Macintosh, NetWare, supported Linux, and supported UNIX,
while Software License Monitoring is only supported on Windows and Macintosh operating systems. (To see
the document “Supported Platforms and Compatibility Matrix for LANDESK® Management Suite”, please
go to: http://community.ivanti.com/support/docs/DOC-23848.)
Understand compatibility with previous versions of Management Suite

Management Suite 2016 Consoles can communicate with devices running Management Suite 8.7 and later.
With older devices, there is no access to the new Management Suite 2016 features. Management Suite 2016
Device Agents authenticate only with authorized Management 2016 Core Servers, preventing unauthorized
Core Servers/ Consoles from accessing Management Suite 2016 Devices.

Management Suite Environment
The Management Suite environment is composed of all the devices that report to and communicate with a
single Core Server. This section gives an overview of the various items commonly found in the Management
Suite environment.
If desired, database information from multiple Core Servers can be combined into a Rollup Database. While a
Rollup Database does not facilitate management of Managed Devices, it does provide ease of reporting,
combining data for up to 200,000 Managed Devices in a single location.
Core Server
The Core Server is the centerpiece of the Management Suite environment. This server acts as the host system
for each of the services that provide most of the Management Suite functionality.
To see the “LANDESK® Core Install, Console Install, and Upgrades Landing Page” go to:
http://community.ivanti.com/support/docs/DOC-23850. Here you can find links to:
 Core Installation and Configuration
o Prerequisites and Preparations
o Install Guides
o Additional Information
 Database Installation and Configuration
o Prerequisites and Preparations
o Best Known Methods

 Troubleshooting
 Momentum (Technical Brief Recordings)
Install / Upgrade to Management Suite 2016

Management Suite supports either a new installation or an in-place upgrade. If you choose to do a side-by-side
upgrade to Management Suite 2016, you will have an operational fallback server to manage all existing agents,
until you upgrade them to the new server. Regardless of the method you choose, the Core Server can be
either a virtual or a physical device.
While there are benefits to running a Core Server in a virtual environment (e.g. backup features and snapshot
features) remember that the hardware requirements listed still apply to the hardware allocation for the
virtualized server.
To download the “LANDESK Management Suite 2016.3 Install Guide” (go to
https://community.ivanti.com/docs/DOC-42248.) There you can download the document in a .pdf format.
In the document are checklists for:
 Planning the Installation/Upgrade Procedure
 Backing-up the existing Core Server
 Preparing the Core Server for Installation/Upgrade
 Installing/Upgrading
 Restoring Files and Settings
 Verifying the Core Server Installation
 Performing Post-Installation Configuration
In addition to these helpful checklists the “LANDESK Management Suite 2016.3 Install Guide” document
provides a helpful matrix detailing the install/upgrade method, the core server, and the database.
Install/Upgrade Method Core Server Database
New Installation Clean install on the same or on new New, clean, database instance
server hardware
In-Place Upgrade Upgrade existing server. (Backup server Same database upgraded during
prior to upgrade.) install. (Backup database prior to
upgrade.)
Clean Core Server
Clean install on the same or on new Upgraded database instance
Installation with an server hardware.
Upgraded Database
Test or Lab Core Server Upgrade existing server. (Backup server Same database upgraded during
Becomes Production prior to upgrade.) install. (Backup server prior to
upgrade.)
Multiple options: new database
Side-by-side Migration New server hardware that will be
configured while the current server instance, or upgraded database
hardware is running

To download the “LANDESK Management Suite 2016.3 Install” file go to
https://community.ivanti.com/community/product_downloads/downloads-SSM. You will only be able to view
downloads if you have a login and a current maintenance agreement. Select to download “LANDESK
Management and Security 2016.3”.
Other installation documents on the Ivanti Community Website

There are many helpful documents on the Ivanti Community Website concerning the installation or the upgrade
of the Core server. Some of these documents include:
 “Prerequisites to Check Before Installing or Patching the LANDESK Core Server”
(located at https://community.ivanti.com/docs/DOC-39874.)
 “Best Known Methods for Installing Microsoft SQL Server 2012 for LDMS”
 “LANDESK Management Suite 2016 Architecture – Overview”
 “Supported Platforms and Compatibility Matrix for LANDESK Management Suite”
 “Recommendations for tuning LDMS and MS SQL for large enterprise Core Servers”
 “Reindexing LANDESK Databases” (located at https://community.ivanti.com/docs/DOC-4362.)
 “How to use the CoreDataMigration.exe tool to migrate core settings”
 “LDMS 2016 Enhanced Security Mode” (located at https://community.ivanti.com/docs/DOC-39948.)
 “Getting Started with Mobility LANDESK Management Suite 2016 & 2016.3”
Management Suite 2016.3 Installation Steps

1. Download the “LANDESK Management Suite 2016.3 Install Guide” from
https://community.ivanti.com/docs/DOC-42248. Use it to plan your installation.

2. Download the installation file from
https://community.ivanti.com/community/product_downloads/downloads-SSM
and run the installation.
Click [Run].

3. Designate the location where you want the installation files to expand, and from where the installation will
run.
Click the [Install] button.

4. The Check for latest updates screen appears.
Click the [Continue] button.

5. The Welcome screen appears.
Select the desired installation language, and click [Continue].

6. The License Agreement screen appears.
Click the I accept the terms in the License Agreement checkbox, and click [Continue].

7. The What do you want to install screen appears.
Select the Core Server radio button, and click [Continue].

8. The Prerequisites screen appears.
If you want to see what prerequisites are required for the installation, click to select the Show all
prerequisites checkbox. (This is optional.) Click [Continue].

9. The How should LANDESK configure your database screen appears.
Click to select the desired option, and click [Continue]. For our class, we selected to Configure a new 10.0
database.

10. The Database Application screen appears.
Select the desired option, and click [Continue]. Select Microsoft SQL Server, presents:

11. The Where do you want to install screen appears.
Select the desired location and click [Continue].

12. The Secure Client Management screen appears.
Decide whether the select the Enable Client Certificate-based Security (Recommended) checkbox, and
click [Continue]. (For our class we did select the checkbox.)
Tip/Comment
The Client Certificate-based Security is fully discussed in the Client-side Certificates portion
of the Agents section of this course.

13. The Ready to install screen appears.
The installation information is displayed. If all is desired options are correct, click [Install]. The installation
occurs. (It usually takes about 30 - 40 minutes to install the Core Server.)

14. The Success screen appears.
The screen offers hotlinks to log files for various aspects of the installation, and lists the steps it took during
the installation. Click [Reboot] to reboot the Core Server, and complete the installation.

15. Now that the installation has completed, and the reboot has occurred, Activate the Core Server.

Management Suite 2016.3 Upgrade Steps
If you have an existing Management Suite 2016.1 Core Server, perform the Upgrade.
1. Download the “LANDESK Management Suite 2016.3 Install Guide” from
https://community.ivanti.com/docs/DOC-42248.
2. Download the installation file from

https://community.ivanti.com/community/product_downloads/downloads-SSM
and run the installation.
3. Designate the location where you want the upgrade files to expand, and from where the upgrade will run.
Click to run the LANDESKSoftware2016.3.exe file.

4. After the extraction of the .EXE file, the Upgrade automatically begins.

5. The License Agreement screen appears.
Click the I Accept the terms in the License Agreement checkbox, and click the [Continue] button.

6. The Prerequisites screen appears.

7. The Ready to upgrade screen appears.
Click the [Upgrade] button.

8. The Success screen appears. Click the [Reboot Required] button, to reboot the Core Server.

9. Now that the installation has completed, and the reboot has occurred, Activate the Core Server.
Management Suite Customer Experience Improvement

Program
In Management Suite 2016 you have the ability to opt in to participate in the Management Suite customer
experience improvement program. If you opt in to the program, the Core Server will collect crash data (if an
Management Suite tool happens to crash) including minimal component usage information at the time of the
crash to help Ivanti understand how the product was functioning at that time in your particular environment.
To opt in to the program, select the “Participate in the LANDESK Customer Experience Improvement Program”
checkbox on the Activate License window.

Core Server Activation
When the Installation of the Management Suite Core Server completes, the Core Server Activation is
automatically launched at the next login.
Ivanti uses a central licensing server at Ivanti headquarters to manage Core Servers’ product and node
licenses. To use Management Suite, you must obtain a user name and password that activates the Core
Server and downloads an authorized certificate. Activation is required on each Core Server before Ivanti
products can be used. Each Core Server can be activated either automatically by the Internet or manually by
e-mail. A Core Server may need to be reactivated in the event that its hardware configuration is significantly
modified.
On a periodic basis, the activation component on each Core Server will generate data regarding the “node
count data” which includes:
 The precise number of nodes being used
 The non-personal encrypted hardware configuration
 The Ivanti Software programs being used
No other data is collected or generated by Core Server activation. The hardware key code is generated on the
Core Server using non-personal hardware configuration factors, such as the size of the hard drive, the
processing speed of the computer, etc. The hardware key code is sent to Ivanti in an encrypted format, and the

private key for the encryption resides only on the Core Server. The hardware key code is then used by Ivanti to
create a portion of the authorized certificate.
After installing a Core Server, it will be configured to automatically launch the activation at the next login. It also
has a Core Server Activation utility. The Core Server can be activated either with an Ivanti account
associated with the licenses purchased or with a 45-day evaluation license. The 45-day evaluation license is
for 100 nodes.
Rollup Core Servers do not need to be activated.
A 45-day evaluation can be changed to a paid license at any time by running the Core Server Activation utility
and entering the Management Suite username and password.
Ivanti provides an authorized certificate based on the node count data. Periodically the node count data is
generated by the activation software on a Core Server, and is sent to Ivanti, either automatically via the
Internet or manually via e-mail. If node count data is not provided within a 30-day grace period after the initial
node count verification attempt, the Management Suite Console may become inactive until the node count data
is provided.
Once a Core Server has been activated, the Management Suite Console’s Configure > Product Licensing
window can be used to view the products and the number of authorized nodes purchased for the account with
which the Core Server authenticates. The date the Core Server verifies node count data with the central
licensing server can also be viewed on the Product Licensing window.
The Core Server does not limit the number of authorized nodes purchased. License information can be viewed
by visiting the Ivanti licensing site at www.ivanti.com/contactus.
Once the Core Server has been activated, the Console can be started by clicking Start > All Programs>
LANDESK > LANDESK Management Console. The credentials used when the Core Server was installed
can be used on the Management Suite Console Logon window. Once logged in, confirm that the Core Server
has been scanned into the core database (it will be visible in the Console in All Devices).
There is a hands-on exercise for Activating the Core Server.
Management Suite Console Types

 Core Server Console
 Remote Console
 Web Console
Core Server Console

The Management Suite Console (Core Server Console) is automatically installed on the Core Server. The
Console is used to interact with the various Management Suite features; e.g., to distribute software, remotely
control Managed Devices, view inventory information, and perform other management functions.
Remote Console
A Remote Console should be installed on the local machines of all Management Suite administrators who
need full functionality or access to all the Management Suite tools.
For additional management ability of devices with the Management Suite Agent, Remote Consoles can be
installed throughout the network. (Ivanti does not incur additional charges for additional consoles.)

To download instructions to install the Remote Console, go to the “Console Add-on: LANDESK Support
Tools” page located at: http://community.ivanti.com/support/docs/DOC-5076.
Web Console
The Web Console offers a subset of the Management Suite Console functionality from the convenience of a
Web browser (for example, no access to OS Provisioning). This allows a Console user to immediately access
the Web Console without any installation. The Console user can simply open a Web browser, enter the URL to
the Core Server (http://[Core Server Name or IP Address]/remote) which will then present to them a login
dialog. The login requires a user and password for someone the Management Suite Administrator has setup to
use a Management Suite Console.
What makes this possible is a Web server that was setup during the initial installation of the Management Suite
Core Server. It can be accessed from the General tab in Configure LANDESK Services.
What Counts as a Managed Node

Items in the Unmanaged Device Discovery table are Discovered Devices and do NOT count as Managed
Devices, whether discovered by Unmanaged Device Discovery (UDD) or eXtended Device Discovery (XDD).
An Unmanaged Device becomes a Managed Device only when the Management Suite Agent is installed on
the device and the device’s inventory adds it to the Management Suite database. A common process for
installing the Management Suite Agent is as follows:
 The unmanaged device is discovered and added to Unmanaged Device Discovery
 A Scheduled Task is created, to deploy a Management Suite Agent or an Advance Agent. (This
removes the device from Unmanaged Device Discovery and adds it to Pending unmanaged client
deployments, found in the Management Suite Console in Network View > Core Server >
Configuration > Pending unmanaged client deployments.)
 Once the Management Suite Agent completes installation an Inventory Scan adds the device to the
Network View. It is now considered a Managed Device. (This removes the device from Pending
unmanaged client deployments.)
Unmanaged devices can be added manually to the database in the Management Suite Console’s Network
View > Core Server > Devices > All devices > Insert New Computer. Manually added devices are listed
under Network View > Core Server > Devices > All devices, as well as Network View > Core Server >
Configuration > User added computers.
The algorithm for counting nodes then is:
(1) the total number under Network View > Core Server > Devices > All devices – minus
(2) the total number under Network View > Core Server > Configuration > Pending unmanaged client
deployments – minus
(3) the total number under Network View > Core Server > Configuration > User added computers – minus
(4) the total number under Network View > Core Server > Devices > Agentless.
Once the Core Server installation is complete, the next step is to create, configure and deploy Management
Suite Agents to Discovered Devices. For more information on deployment, refer to the “Agents” module.
The Lab Guide has an exercise to activate the Core Server.

Port Usage
When using Management Suite in an environment that includes firewalls (or routers that filter traffic),
information on which ports need to be opened at the firewalls is crucial. To see the document “Ports used by
LANDESK Management Suite – Full List”, go to: http://community.ivanti.com/support/docs/DOC-1591.
Core Database
Management Suite relies on a Database Management System (DBMS) to store all of the data that is collected
while using Management Suite. This DBMS does not typically reside on the Core Server unless the total node
count is not expected to exceed 2000 nodes. The volume of the data and the performance of the server require
the database to be offloaded onto a dedicated server elsewhere.
The following are supported database management systems:
 Microsoft® SQL Server® 2014 Express Edition -- Bundled with Management Suite Installation. Default
Database for less than 500 nodes (Dependent on the size of the scans and the vulnerability information
that is scanned for. The number of clients that will go into the database can increase or decrease but
500 is the typical size for most customer installations.)
 Microsoft® SQL Server® 2012 Standard/Enterprise
 Microsoft® SQL Server® 2014 Standard/Enterprise
To see the “LANDESK Management Suite 2016 Architecture - Overview” page, go to:
http://community.ivanti.com/support/docs/DOC-40046.)
Core and Database Server Configurations

1-2000 Devices
If you manage 1 – 2,000 devices, the Core Server, Console, Web Console server, and the core database can
be installed on one server. For this configuration, the default Microsoft SQL Server 2014 Express Edition
database generally can be used. If your organization anticipates growing beyond 2,000 devices, consider
installing the database on a second Server.
Each Microsoft SQL Server 2014 Express Edition database has a maximum size limit of 4 gigabytes with a
maximum of eight concurrent SQL processes.
2,000+ Devices –Core Database on a Second Server

If you manage more than 2,000 devices, the Core Server, Console, and the Web Console server, can be
installed on one server, while the Database can be installed on another server. The performance (largely
based on hardware) dictates when to further create yet another separate core server and accompanying
database.
There are also other performance adjustments that can be made on the Database server. The Database and
its log file can be placed on separate drives or arrays, for example. The log can also be set to overwrite data in
the log file when the entire transaction has committed and completed the data write to the database file. (In
Microsoft SQL the setting is “Simple Recovery” mode.) This keeps the log file smaller which can speed up
database performance is reading and writing.

Database Size
If you want to estimate the size of the database, so as to apportion the original database size when you create
it initially, estimate that each managed node will take 5 to 10 Megabytes. So if I estimate I will manage 4,000
nodes, I might choose to make the initial database size 40 Gigabytes (using the higher-end estimation).
Naturally, workstations, and laptops, likely have more software and history than servers, and especially mobile
devices. So you may want to estimate the storage requirements accordingly.
Relational Database
Management Suite uses a relational database, as opposed to an object-oriented database. Object-oriented
databases generally have fewer tables with more data in each table, while relational databases generally have
more tables with less data in each table. Queries obtain results faster in a relational database compared to an
object-oriented database. The Rollup database is also a relational database.
If Microsoft SQL Express is the database of choice, the default Core Server installation can install it on the
Core Server when the Core Server installation runs. If using a Microsoft SQL database, it can be installed on
the Core Server (if the node count is not expected to exceed 2000) or onto another server (if the node count
will exceed 2000 devices). In this case, the database must be created before the Core Server is installed.
In any case, during the Core Server installation, a dialog window opens, asking for:
 the database server name and instance
 the database name
 the login name and accompanying password
This data appears on the Configure Services > General tab. This information was also written in the registry
of the core server in:
HKEY_LOCAL_MACHINE\SOFTWARE\LANDESK\ManagementSuite\Core\Connections\Local.
Unicode or Universal Database

The Management Suite database utilizes the UTF8 Universal format. This allows the following:
 Update a database from one language to a different language
 Update a rollup database (regardless of language)
 Support of managed devices (regardless of language)
Changing the Database

If you installed the core using Microsoft SQL Express, and found you needed to go to the purchased version,
Microsoft SQL Server/Enterprise, you could easily change the configuration of Management Suite to point to

the alternate database by modifying the settings in Configure Services > General. This would also change
the pointers in the registry.
Database Utilities
Management Suite is equipped with utilities to for the Management Suite database.
CoreDbUtil.exe — Database Utility

This Management Suite utility (located in the Program Files\LANDesk\ManagementSuite directory on the Core
Server) has the following multiple functions:
 It is used automatically during the installation process to create the Core Database.
 It creates tables, key constraints, and all that make up the schema of the database.
 It publishes the application list (LDAPPL3 files updates)
 It updates reports
 It configures the database specified to work with Management Suite.
The CoreDbUtil.exe file can be outside of the installation process to perform the above tasks.
DbRepair — Database Repair Utility

The Database Repair Utility can be obtained from support. This is used to clean up data that ends up in the
database without pointers and cleans out data that appears as ‘jibberish’.
Core Database Maintenance

There are two primary maintenance settings. The maintenance setup by the DBMS vendor optimizes the
database for speed, and Management Suite maintenance which clears out old records (if configured to do so)
and helps to assure accuracy.
DBMS Maintenance
The DBMS maintenance is setup in the database tools via a wizard and does the following:
 Reindexes the tables in the database (DBCC reindex [tablename])
 Resets the database consistency checker (DBCC)
 Backs up and logs the backup of the database
 Clears free space (whitespace) for database use (much like making contiguous space to write)
There are documents on the Community Website to help setup databases and their maintenance.
To go to the “LANDESK Database Landing Page” go to: http://community.ivanti.com/support/docs/DOC-
23798. This page contains links to:
 Prerequisites
o Prerequisites for Database Management Systems
o SQL Server Authentication is required for LANDESK® Management Suite
o Four things to know and plan on before you create your database
 Tuning and Maintenance
o Management Suite Database tuning for Microsoft 2008 R2 and 2012
o Tuning Management Suite Database utilization and storage usage by component
o Maintenance Plan for SQL Express
o Reindexing LANDESK Databases
o Management Suite Recommended Database Maintenance
 Additional Options on Information
 Troubleshooting databases

The document “Use the Maintenance Plan Wizard” for SQL Server 2014 can be downloaded at:
https://msdn.microsoft.com/en-us/library/ms191002(v=sql.120).aspx.
Management Suite Database Maintenance

The maintenance cycle set up by Management Suite runs on the database every day at a specified time. It can
be configured to do the following:
 Remove old devices (not recently scanned by inventory)
 Remove duplicate devices
 Delete software removed from a managed device and reported as such from an updated inventory scan
 Remote deleted task files
 Add NIC Addresses to the ignore list is the configured threshold has been reached
 Clear out the Provisioning History as configured
When a new record is received for a managed device, the record in the database is updated with the new
information. Computers that are deleted from the database by the Console are deleted immediately. When the
maintenance cycle runs (the default is 11:00 pm) the settings are read and actions are taken to delete old
devices and delete duplicate devices. To keep the database accurate and current, daily maintenance is
scheduled by default.
This is an automatic process controlled by the Inventory Service. The service creates an event in the
Application log whenever the maintenance process starts and completes.
The Management Suite Maintenance and other database events log to the Application Event Log on the Core
Server. The start of maintenance is event 2389 and the stop maintenance is event 2388.
Core Server Security

Public Key Infrastructure
To watch a video “LANDESK Management Suite – Public Key Infrastructure Use”, which explains and
demonstrates Public Key Infrastructure Use in Management Suite, please go to:
https://community.ivanti.com/support/docs/DOC-33778.
Public-key Infrastructure (PKI) is a key based security. Public-key Infrastructure Security has been
implemented into Management Suite for Secure Socket Layer (SSL) communication. Client systems loaded
with the Management Suite Agent authenticate to authorized Core Servers using this key based method
preventing unauthorized access to Management functions on managed devices. These keys are generated
during install and placed on the file system of the Core Server. There is no need for a separate certificate
authority to create these keys on your behalf since they are self-generated during install and do not need to be
trusted by anything outside of the Management Suite environment. Each Core Server and Rollup server that is
installed in the infrastructure has a unique set of keys to authenticate with managed devices.
The following is an explanation of these key files:

<keyname>.key: The .KEY file is the private key for the Core Server that it was generated on, and only
resides on the Core Server. If this key is compromised, the Core Server and managed device communications
are no longer considered secure. Keep this key secure. For example, do not use e-mail to move it around,
never put it in a folder where it is accessible by unauthorized individuals, etc.
<keyname>.crt: The .CRT file is the public key for the Core Server. The .CRT file can be viewed in a standard
text editor for more information about the public key and the Core Server with which it is paired. It is not
necessary to keep the public key secure.
<hash>.0: The .0 file is a trusted certificate file and has content identical to the .CRT file. However, it is named
in a manner that allows the managed device to find it quickly on the file system where numerous other
certificate (.crt) files may exist. The name is a hash (checksum) of the certificate’s subject information, which
can be found in the .CRT file. There is an [LDMS] section in the .CRT file that contains “hash=value”. The
value displayed here indicates the name of the .0 (Hash) file. The <hash>.0 file also exists on the managed
device in the Program Files\LANDesk\LDClient\ folder. The purpose for the .0 file on the managed device is
to enable that machine to authenticate to Core Servers and process commands from servers that have a
corresponding private key.
<keyname>.cer: This certificate information telling purposes, to whom it is issued, by whom it was issued, and
the date range the certificate is valid. This is used to secure HTTPS traffic occurring between the Global
Scheduler Proxy and the Global Scheduler Web Service.
<keyname>.p12: This contains the Personal Information Exchange information.
All keys are stored on the Core Server in \Program Files\LANDesk\Shared Files\Keys. The <hash>.0 public
key is also in the LDLOGON folder and needs to be there by default. The <keyname> is the certificate name
provided during Management Suite Setup. During Setup, it is helpful to provide a descriptive key name, such
as the Core Server's name (or even its fully qualified name) as the key name (example: ldcore or
ldcore.org.com). This will make it easier to identify the certificate/private key files in a multi-core environment.
There is an exercise on the Public Key Infrastructure in the Lab Guide.
Important Note
You should back up the contents of your core server's Keys folder and keep the medium in a
safe, secure place. If for some reason you need to reinstall or replace your core server, you won't
be able to manage that core server's devices until you add the original core's certificates to the
new core.
Sharing Keys among Core Servers

Devices will only communicate with core and rollup core servers for which they have a matching trusted
certificate file. For example, let's say you have three core servers, managing 5,000 devices each. You also
have a rollup core managing all 15,000 devices. Each core server will have its own certificate and private keys,
and by default, the device agents you deploy from each core server will only talk to the core server from which
the device software is deployed.
There are two main ways of sharing keys among core and rollup core servers:

1. Distributing each core server trusted certificate (the <hash>.0 file) to devices and their respective core
servers. This is the most secure way.
2. Copying the private key and certificates to each core server. This doesn't require you to do anything to
devices, but since you have to copy the private key, it exposes more risk.
In our example, if you want the rollup core and Web console to be able to manage devices from all three cores,
you need to distribute the rollup core's trusted certificate (the <hash>.0) file to all devices, in addition to
copying the same file to each core server's ldlogon folder. Alternatively, you can copy the certificate/private key
files from each of the three core servers to the rollup core. This way, each device can find the matching private
key for its core server on the rollup core server.
If you want one core to be able to manage devices from another core, you can follow the same process, either
distributing the trusted certificate to devices or copying the certificate/public key files among cores.
If you are copying certificates between standalone cores (not to a rollup core), there is an additional issue. A
core won't be able to manage another core's devices unless it first has an inventory scan from those devices.
One way of getting inventory scans to another core is to schedule an inventory scan job with a custom
command line that forwards the scan to the new core. In a multiple core scenario, using a rollup core and the
Web console is a simpler way to manage devices across cores. Rollup cores automatically get inventory scan
data from all devices on the cores that get rolled up to it.
Distributing Trusted Certificates to Devices

There are two ways you can deploy trusted certificates to devices:
1. Deploy a device setup configuration that includes the core server trusted certificates you want.
2. Use a software distribution job to directly copy the trusted certificate files you want to each device.
Each additional core server trusted certificate (<hash>.0) that you want devices to use must be copied to the
core server's ldlogon folder. Once the trusted certificate is in this folder, you can select it within the device
setup dialog's Common base agent page. Device setup copies keys to this folder on devices:
Windows devices: \Program Files\LANDesk\Shared Files\cbaroot\certs
Mac OS X devices: /usr/LANDesk/common/cbaroot/certs
If you want to add a core server's certificate to a device, and you don't want to redeploy device agents through
device setup, create a software distribution job that copies <hash>.0 to the folder specified above on the
device. You can then use the Scheduled tasks window to deploy the certificate distribution script you created.
The following is an example of a custom script that can be used to copy a trusted certificate from the ldlogon
folder of the core server to a device. To use this, replace "d960e680" with the hash value for the trusted
certificate you want to deploy.
; Copy a trusted certificate from the ldlogon directory of the core server
; into the trusted certificate directory of the client
[MACHINES]
REMCOPY0=%DTMDIR%\ldlogon\d960e680.0, %TRUSTED_CERT_PATH%\d960e680.0
Copy certificate/private key files among core servers
An alternative to deploying certificates (<hash>.0) to devices is to copy certificate/private key sets among
cores. Cores can contain multiple certificate/private key files. As long as a device can authenticate with one of
the keys on a core, it can communicate with that core.

Note
When using certificate-based remote control, target Devices must be in the core database. If
you're using certificate-based remote control security with Devices, you can only remote control
Devices that have an inventory record in the core database that you're connected to. Before
contacting a node to launch remote control, the core looks in the database to ensure the
requesting party has the right to view the device. If the device isn't in the database, the core
denies the request.
To copy a certificate/private key set from once core server to another
1. At the source core server, go to the \Program Files\LANDesk\Shared Files\Keys folder.

2. Copy the source server's <keyname>.key, <keyname>.crt, and <hash>.0 files to a floppy disk or other
secure place.
3. At the destination core server, copy the files from the source core server to the same folder (\Program
Files\LANDesk\Shared Files\Keys). The keys take effect immediately.
Care should be taken to make sure that the private key <keyname>.key is not compromised. The core server
uses this file to authenticate devices, and any computer with the <keyname>.key file can perform remote
executions and file transfer to a Management Suite device.
There is a hands-on exercise for Public Key Infrastructure Security.
Client certificate model

The Client certificate model generates a security key with which secure data will be encrypted. After
selecting the Client certificate model, stored passwords should be updated. These updates passwords are now
encrypted using the security keys, as a security measure.
Stored passwords include:

 Preferred servers
 Run-As credentials in Software Distribution Packages
 Distribution and Patch Agent settings
 Provisioning Variables and Passwords
Clients with previous agent versions will not be able to decrypt the new passwords and will need to be
updated.
To enable the Client certificate model, open the Console and click Configure > Security. The Security settings
window opens and check runs to see if clients support the client certificate model. If clients support the
enhanced security model, you can select the Client certificate model checkbox, and click [Save]. A window
appears which states: “Continuing will change the current encryption model. Previous agent versions will no
longer be able to decrypt encrypted data. Once completed, it is recommended to update your passwords for
Preferred Servers, Package Run-As credentials, Distribution and Patch Agent Settings, and Provisioning
variables and passwords.”

The Security settings showing that all clients support the client certificate model.
The Security settings showing that not all clients support the client certificate model.
The Key manager page shows the AES-256 keys that have been generated, and which will be used.

Once AES-256 keys have been enabled and generated, they will need to be approved. If you click the Client
certs hot-link, the Manage client certificates page of Client Access will appear. (This can also be accessed by
clicking Configure > Client Access.)
As clients appear in the database, the certificates are designated unapproved. The Management Suite
Administrator will need to periodically go in and approve the certificates. If desired, the administrator can check
the “Automatically approve new certificates (not recommended) checkbox and have them automatically
approved when they are created. (The reason this is not recommended is it is less secure.)
How this will work now, is if the client is to receive a software distribution package, or a provisioning template,
or a vulnerability patch, etc. it may need to download the package from a share with a username and
password. If the client has a certificate which is approved, the core will give the client the AES-256 certificate it
will need to decipher the password to access the share. As time passes, a rouge device may obtain the
certificate. So, periodically a new certificate can be made, distributed, and approved as needed, to maintain
security.
There is a hands-on exercise for Client Certificates for Security.
Management Suite Shares and Directories

The Management Suite file structure is organized into four main folders which are configured as Active
Directory shares. As a Management Suite Administrator, it is important that you understand this structure as
well as the content and function of each share.

 ldmain share: Server applications are stored in the ldmain share,
\Program Files\LANDesk\ManagementSuite\ldmain.
o The Administrators group must have Full Control of ldmain.

o The LANDESK Management Suite group members have Read rights.
o Do NOT grant ldmain rights to other users. This directory is for Administrators only. Granting other
users rights would compromise the integrity of the ldmain share.
 ldlog share: Logs created by Management Suite are stored in the ldlog share,
\Program Files\LANDesk\ManagementSuite\ldmain\log. These log files are helpful for troubleshooting.
Please refer to the Server Side Log File Locations by Management Suite Component in the “Core”
section of this document for a more complete listing of the log files contained in the ldlog share.
 ldlogon share: Applications to be run on Managed Devices and agent software are stored in the ldlogon
share. When deploying the Management Suite Agent, the Applications and software and copied out to
managed devices from
\Program Files \LANDesk\ManagementSuite\ldlogon.
o The Administrators group must have Full Control here.
o The Everyone group must have Read Only rights here.
o All software which updates periodically on managed devices is stored and copied out from here.
 scripts share: Software distribution scripts, and managed scripts, are stored and launched from the scripts
share, \Program Files\LANDesk\ManagementSuite\Scripts. Here, the LANDESK Management Suite
group should have Full Control rights.
Federal Information Processing Standard 140-2 Mode

The Federal Information Processing Standard (FIPS) 140-2 is a National Institute of Standards and
Technology (NIST) security standard that defines an allowable set of cryptographic functions.
The NIST was created by the U.S. Government to provide technical guidance, and coordination of government
efforts in the development of standards and guidelines in the management of computer and related
telecommunications systems in the Federal government. In Canada, the Communication Security
Establishment (CSE) worked with the NIST to assure cryptography based standard and assisted FIPS 140-2
validation in the Cryptographic Module Validation Program (CMVP) so products validated as conforming to
FIPS 140-2 are accepted by the Federal agencies of both countries for the protection of sensitive information
(U.S.) or Designated Information (Canada).
In order to have a Remote Control session with a device with sensitive information (U.S.) or Designated
Information (Canada), the Remote Control session must use FIPS 140-2 enabled Secure Socket Layer (SSL)
encryption for communication from the managed Windows device, to the CSA, to the core server.
FIPS 140-2 support requires Management Suite Version 9.5 SP1 or later, and a CSA with Gateway service 4.3
or later.
The Management Suite components that support FIPS 140-2 are:
 The LANDESK® Management Gateway Service (which provides CSA communication).
 The Remote Control Viewer (both HTML and Legacy versions).
 The broker daemon on the CSA.
 ProxyHost.exe on the remote device (which provides general Management Suite agent communication).
 The LANDESK Remote Control Service (ISSUSER.EXE) on the remote device (which connects with the
Remote Control Viewer on the device initiating Remote Control).
No other components (such as the console, roll-up core, and so on) are FIPS-enabled.

Enabling FIPS on the Core Server creates a new set of FIPS 140-2 compliant SSL security certificates. The
SSL certificate set is created in the C:\Program Files (x86)\LANDesk\Shared Files\Keys directory. The old SSL
certificates are moved to the C:\Program Files (x86)\LANDesk\Shared Files\Keys\Backup\<Date and Time>
directory.
This means Agents deployed prior to enabling FIPS 140-2 will no longer be able to be managed until a new
Management Suite Agent is deployed. All scheduled tasks, remote control sessions, etc. will not be possible
until a new Management Suite Agent (with a new public FIPS 140-2 compliant SSL certificate) is deployed.
When you enable FIPS 140-2, the Core Server rebuilds all Management Suite Agent configurations so that
they include a new FIPS 140-2 compliant SSL public security certificate. These new Agent configurations can
be deployed. (You can copy the backed up LANDESK_<number>.key file back to the KEYS directory to have
communication between the devices use the old key for the Agent deployment task. Then you can remove the
old .KEY file when all Agents have been redeployed.)
The Best Known Method (BKM) if you are going to implement FIPS 140-2, recommends that you enable FIPS
140-2 at the beginning of the deployment process, and then send an agent just once to devices to be
managed.
If you disable FIPS 140-2 after enabling it, and later re-enable FIPS 140-2, the core will reuse the certificate
you created the first time you enabled FIPS 140-2. In this case you wouldn't have to redeploy agent
configurations a second time.
Steps to Enable FIPS 140-2

In order to enable FIPS 140-2, the following steps are required:
1. Enable FIPS mode on the Cloud Services Appliance.
2. Enable FIPS mode on the core server.
3. Deploy a Management Suite Agent configured to use the Cloud Services Appliance and FIPS 140-2 to
each Windows device which might be remotely controlled via the Cloud Services Appliance.
4. Deploy a Management Suite Agent configured with Remote Control and the new certificate to each device
you want to manage.
Enabling FIPS 140-2 mode on the Cloud Services Appliance
On the Gateway service configuration tab select 1 for Server FIPS 140-2 mode. (0 = off, 1 = on, default is 0).
(Near the setting is the warning, “NOTE: not all clients will support FIPS mode. Be sure your client software
does before changing this value.”)
Enabling FIPS 140-2 mode on the Core Server
1. Open the Console on the Core Server.
2. Click Configure > Services.
3. On the General tab, select the FIPS 140-2 checkbox. (A window appears stating: “Enabling FIPS 140-2 on
this server requires that a new core certificate be generated. If enable, existing client systems won’t work
until an updated Management Suite agent is installed on them. Would you like to enable FIPS 140-2
mode?)
4. Click [Yes]. (If you have configure a Cloud Services Appliance setting on the Core Server, a Configure
Services window will appear stating: “The LANDESK® Management Gateway Service must be restarted
before your changes will take effect. Do you wish to restart it now?)
5. If this Configure Services window appears, Click [Yes].

6. A Configure Services window appears stating: “You must restart the services that use the database before
your changes will take effect.” Click [OK].
7. Click [Refresh Settings]. (Assure the FIPS 140-2 checkbox remains selected.
8. Click [OK]. (The Configure Ivanti Services window closes.)
Note
If FIPS 140-2 is enabled on a Core Server, each Cloud Services Appliance for that Core Server
must be configure to us FIPS 140-2 mode.
Core Auditing
Core Auditing provides ability to select, in a methodical and exact manner, what to audit. This capability
enables administrators to audit with precise detail actions taken by console users. Audited events are written to
secure audit logs in the Management Suite database, putting to rest audit compliance concerns regarding data
tampering. Additionally, audited events can also be configured to be written to the Application Event Log on the
Core Server.
To those granted auditing rights, Auditing events can be queried, and auditing logs can be archived and
restored as needed. To view audited events, open the Auditing tool (click Tools or Toolbox > Administration
> Auditing). Default queries allow viewing all audited events for:
 Last 24 Hours
 Last 7 Days
 Last 30 Days
Queries concerning auditing can also be created in the Custom Queries section.
On the Auditing Toolbar are options to archive data as well as to restore from archived files.
Core Auditing Rights and Roles

The permission added for assigning rights to users is the Auditing permission. It has a View right and an Edit
right. There are two new roles in the User management tool, including the Auditing Configuration role (which
includes the Edit and View rights to the auditing permission) and the Auditor role (which includes the View
right to the auditing permission).
The Auditing Configuration role, with edit and view rights, allows a Console User to configure which events get
audited. The user assigns which events to audit by clicking Configure > Services and accessing the Auditing
Configuration tab. (Note: if the Auditing Configuration tab is not visible in SvcCfg, the logged in Console User
does not have the Auditing Configuration role. Add the role to the user and close and login to the Management
Suite Console again.)

The events are stored in the database. By selecting the option to “Write auditing events to the Event Log” the
events can are added to the Application Event Log as well.
Suggested Auditing Guidelines

Decisions concerning which events to audit are important. If the Administrator were to select all events, the
database would become large very quickly, affecting both database performance as well as making the data so
voluminous that finding an exact event would be extremely difficult.
An example of what is added to the event log is shown.

There is a hands-on exercise for Configuring Auditing on the Core Server.

Core Server Check for Understanding
1. What considerations need to be weighed when deciding whether to perform:
a. New Installation
b. In-place Upgrade
c. Side-by-side Migration
2. What checklists are provided in the Management Suite 2016.3 Install Guide that aid in the install/upgrade
of the Core Server? What are the desired outcomes of the checklists and why are they important?
3. What considerations need to be weighed when deciding whether to run the Core Server in a virtual
environment versus a physical environment?
4. How do you install a Remote Console, and what is its purpose? What is the rule of upgrading and applying
service packs concerning the Core Server and the Remote Console(s)?
5. What is a Rollup Core Server and what is its purpose?
6. What database software and versions are supported in Management Suite 2016?
7. What are the two types of database maintenance, and what is the focus of each type?
8. What security features are in Management Suite is to protect the Core Server, and Managed Clients?
9. What should a company expect if they select the “Participate in the LANDESK Customer Experience
Improvement Program” checkbox, on the Activation Page?

Consoles
Module Objectives
In this Consoles section you will:
 Differentiate use on different Management Suite Consoles
 Configure single sign-on to the Console
 Navigate the Consoles
 Select themes in the Console
 Outline use of Console Grouping
 Outline the Setup Wizards and their Functions
 Launch the Admin and Remote Consoles
 Define the use of fast views in the Console
 Configure and use columns in the Console
 List Web Console Navigation Basics
 Configure and use Role-Based Administration
 Schedule Tasks
 Demonstrate use of the Diagnostics Tool
 Cite IPv6 Communication from the Client to the Core Server
 Tell about Credant™ Integration

Console Overview
The wonderful, magnificently efficient, central management of enterprise devices, provided by Management
Suite 2016, begins with use of Consoles. Through the console administrators perform management functions.
From a single console, assigned users can see devices assigned to his/her scope, and perform functions
enabled by his/her granted rights. Depending on the assigned rights he/she can:
 View inventory, run queries, run reports
 Remote Control to view the device as if there at the end-node to diagnose and assist
 Distribute or Update software
 Change configuration settings
 Deploy OS images and migrate user profiles
 Perform numerous other tasks made possible by Management Suite tools
Consoles
There are three (3) Administrator Consoles available in Management Suite
1. The Core Server Console

2. The Remote Console
3. The Web Console
Core Server Console

The Core Server Console is installed automatically, when Management Suite is first installed. It is sometimes
called the Administrative Console or Admin Console for short. It is the only console which has access to the
Configure > Services tool. (This tool affects services and settings which apply to the Core Server and
therefore ALL console users, so this ability is purposely limited to being run from the Core Server.) All tools can
be accessed from this console.
Remote Console
The Remote Console is installed from the Management Suite Setup DVD onto select Windows PCs, and
allows console users to perform Management Suite tasks from his/her workstation. Depending on the Rights
assigned to users, the Remote Console can allow access to all that is available on the Admin Console except
the Configure > Services tool. (This tool affects services and settings which apply to the Core Server and
therefore ALL console users, so this ability is purposely limited to being run from the Core Server.)
There are a number of Community documents concerning the Remote Console. To read: “LANDESK Desktop
Console Landing Page”, please see: http://community.ivanti.com/support/docs/DOC-23832. There are videos
available on:
 Console Installation
 Console Overview
 Console Role-Based Administration
 Console Layout Groups
 Console Layout Columns
There are articles available on:

 How to Silently Deploy a Console
 Installing the console on Terminal Server
 What do these icons in the Desktop console mean

 Various articles on how to Troubleshoot the Console
Web Console
The Web console is a scaled down version of the Remote Console, which includes a subset of the
functionality. It runs from a web browser and does not require the installation of any software, other than a few
components that enable remote control functionality.
Since the Web Console does not install software, you need to click Download tools from the Remote access
tool in the Web Console to install the tools to use Remote Control.
When you click Download tools a window appears presenting you to following options:
 LANDESK Application Launcher: to handle remote control links and buttons throughout the web
application. This will load the “LANDESK UrlHelper Utility” application.
Below this are links to install necessary applications for remote control, including:
 Remote Control Viewer: to initiate remote control sessions and add the “LANDESK® Software Remote
Control Console for Mozilla” application.
 Secure shell (ssh): to initiate secure shell connections and add the “LANDESK® Putty Secure Shell for
Mozilla” application (for use on Mac, Unix, and Linux managed devices).
 Secure ftp (sftp): to initiate secure ftp connections and add the “LANDESK® Putty Secure FTP for Mozilla”
application (for use on Mac, Unix, and Linux managed devices).
You can choose to install any combination of tools you require.
Launching the Web Console

To login to the Web Console, launch http://[CoreServerName or IP Address]/remote on a web browser.
The scope and rights setup by a Management Suite Administrator will apply to the user who logs in.
Single Sign-on into the Console

Single sign-on allows a user to open the Console without prompting the user for a password. The follow
options are available:
 None: This option requires entering User name, Password, and clicking the [Log in] button to log in to the
Console. Single sign-on is not enabled.

 Only: This option presents a pop-up “User Agreement” box. This is used in Federal Standard, Health
Insurance Privacy and Portability Act (HIPPA), and Sarbanes-Oxley (SOX) Act standard environments.
This fulfills the federal single sign-on standards. After the user clicks [Yes] the windows credentials
(username and password) are passed through so the user can click [Login] so without entering a
password, the console opens.
 Only (no popup): This option passes through to the Console the Windows credentials used to log in to the
device. There is no pop-up presented, nor is there a need to click the [Log in] button.
 Mixed: This option also passes through to the Console the Windows credentials used to log in to the
device. However, this option requires you to click to select the [Log in] button.
To select one of the single sign-on options, select Configure > Services in the Console, and go to the
General tab. The Single Sign-on options are presented at the bottom of the page.
Steps to Enable Single Sign-on:
First, login to the Console:

1. On the Core Server, click the Management Console icon. (The Management Suite window appears.)
a. In the User name field, type the Domain\Username.
b. In the Password field, type the password.
c. Click [Log in]. (The Console opens.)
To configure single sign-on:

1. In the Console click Configure > Services. (The Configure Ivanti Services Window appears.)
2. On the General tab, in the Single Sign-on field, select the desired setting.
3. Click [Apply].
4. Click [OK]. (The Configure Ivanti Services Window closes.)
There is a hands-on exercise for Configuring Single Sign-On to the Console.

Management Suite Console Navigation Basics
The Management Suite Console (the Console) is accessed from Start > All Programs > LANDESK >
LANDESK Management Console, or by launching C:\Program Files\LANDesk\
ManagementSuite\Console.exe.l
Tool Menu
The Tool Menu allows you to choose specific actions in the Console. For example if the administrator clicks the
Tools action, the various tools appear and can selected to open within the Console. The Tool Menu contains
the following items:
 File: Allows Console users to select to exit the Console.
 Edit: Allows Console users to cut, copy, paste, delete, or rename selected devices. In Edit, selecting
All devices allows access to Insert New Computer, Import Leasing Information, View As Report,
Export as CSV, Import, and Columns.
 View: Allows Console users to access the Toolbox, Auto Inspector, Inventory History, or Refresh.
 Tools: Allows Console users to access all the tools the user has been given rights to access.
 Configure: Allows Console users to access various configuration items in the Console.
 Window: Allows Console users to choose which window in the Console they wish to have active.
 Help: Allows Console users to access Online Help, Setup Wizards, and Console Information.
Toolbar
The Toolbar contains several frequently used function buttons that are automatically applied to items that are
selected in the various views within the Console. For example, if the administrator selects a managed device in
the inventory list and clicks the Delete toolbar button, the managed device is deleted from the inventory.
The Toolbar contains the following buttons:
 Cut: Cuts the selected information to the system clipboard.

 Copy: Copies the selected information to the system clipboard.
 Paste: Pastes the copied information from the system clipboard.

 Delete: Deletes the selected item.
 Refresh: Updates the user’s currently cached scope in the Network View.
 Refresh Scope: Looks at the user’s assigned scopes and re-caches the effective scope and resulting
device list.
Core Server Menu

The Core Server Menu allows a Console user to select which Core Server to which he/she wants to connect.
This enables a Console user to "manage" all of their Core Servers from a single Console (if rights for such
actions have been granted).
Toolbox Menu
The Core Server Menu allows Console users to lock, pin, or close the Toolbox. The Toolbox provides a pallet
of tools frequently used by the Console users. The Toolbox can be viewed in the Console by clicking View >
Toolbox.
Tools
The Tools feature allows Console users to access the tools to which the users are granted rights, in order to
carry out the functions which they need to be completed. Although there are a few exceptions which are
addressed later, clicking a Tool opens a window along the bottom of the Console, containing tool-specific
controls for performing the various tasks as they relate to the Tool.
Tool Groups
The Tools are logically grouped according to relevance to each other as follows:
 Favorites (available only in the Toolbox)

 Administration
 Configuration
 Data Analytics
 Distribution
 Power Management
 Provisioning
 Reporting / Monitoring
 Security and Compliance
Network View
The Network View is the main window of the console and is the starting point for most administrative tasks.
The Network View is the only window that is always visible. Network View organizes global information stored
in the database into a hierarchical tree structure divided into:
 Devices
 Users
 Virtual OS Hosts
 Queries
 Scopes
 Configuration
 Inspector Results
 Directory

Devices
The Devices section contains Managed Devices which are configured with the Standard Management Suite
Agent (which have sent an inventory scan) and is divided into:
 My devices: Lists devices for the currently logged-in user, based on the user’s scope. This is helpful to
subdivide into Device Groups what is likely a very large number of devices. A Console user can create
device subgroups only under My devices. Users can add devices to their My devices group, or any of its
subgroups, by copying and pasting them from the Public devices and All devices groups. Users can also
click and drag devices from Public devices and All Devices into their My devices group.
 Public devices: Lists devices a Management Suite Administrator has added from the All devices group.
Users with the Management Suite administrator right see all of the devices in this group, while other
Console users see only the devices allowed by their scope. Only a Management Suite Administrator can
create a subgroup under Public devices.
 All devices: Lists all Managed Devices that can be seen by the currently logged-in user, based on the
user’s scope, in a flat list (no subgroups). For a Management Suite Administrator, All devices lists all
managed devices that have been scanned into the core database. Devices configured with the Standard
Management Suite Agent automatically appear in the All devices group/folder when they are scanned into
the core database by the inventory scanner.
 Computers: Lists all Computers, Servers, and Laptop Computers, which have the Management Suite
Agent installed. The devices which can be seen by the currently logged-in user are based on the user’s
scope, and are displayed in a flat list (no subgroups).
 Mobile: Lists all Tablets, and Phones which have the Mobility Manager Agent installed. Devices that can
be seen by the currently logged-in user are based on the user’s scope and are display in a flat list (no
subgroups).
 MDM managed: Mobile Device Managed devices, whether iPhone or Android devices.
 Agentless: Devices which are inventoried but do not have a Management Suite Agent installed. The
inventory is gathered by a device elected by Self-elected Subnet Services.
 Devices with older agents: Lists all Managed Devices that report in to the Core but do not have the
current version of the Management Suite Agent.
 Computers: Hardware Password Managed devices: Lists all devices which have ThinkVantage utilities
enabled. Devices in this group can utilize the ThinkVantage tools for management. The group lists
Computers and Hard-disks for password management.
Users
The Users section lists the users who were logged into the managed device at the time of the last inventory
scan.
Virtual OS Hosts
The Virtual OS Hosts section of the tree structure contains managed devices, which are virtual hosts, stored in
the database. The Virtual OS Hosts section is divided into:
 My virtual OS hosts: Lists virtual OS hosts for the currently logged-in user, based on the user’s scope. A
user can create device subgroups only under My virtual OS hosts. Users can add devices to their My
virtual OS hosts group, or any of its subgroups, by copying and pasting them from the Public virtual OS
hosts and All virtual OS hosts groups. Users can also click and drag virtual OS hosts from public virtual OS
hosts and All virtual OS hosts into their My virtual OS hosts group.
 Public virtual OS hosts: Lists devices an Administrator has added from the All virtual OS hosts group.
Users with the administrator right see all of the devices in this group, while other Console users see only
the devices allowed by their scope. Only an administrator can create a subgroup under Public virtual OS
hosts.
 All virtual OS hosts: Lists all virtual OS hosts that can be seen by the currently logged-in user, based on
the user’s scope, in a flat list (no subgroups). For an Administrator, All virtual OS hosts lists all managed
virtual OS hosts that have been scanned into the database. Virtual OS hosts configured with the Standard

Management Suite Agent automatically appear in the All virtual OS hosts group/folder when they are
scanned into the database by the inventory scanner.
 User virtual OS hosts: (Administrator only) Lists all of the virtual OS hosts in the database, organized into
user subgroups. User subgroups are named with user login IDs (i.e., computername\user account, or
domain\user account). Each user group contains the virtual OS hosts that appear in that user’s My virtual
OS hosts group.
Queries
The Queries section of the tree structure contains queries stored in the database. The Queries section is
divided into:
 My queries: Lists queries either created by the currently logged-in user, or added to the user’s User
queries group by an Administrator. A user can create, modify, and delete query groups and queries under
their My queries group. Users can also copy queries to this group from the Public queries group.
 Public queries: Lists queries that an Administrator, or a Console user with the Public Query Management
(PQM) right, has added. Only users with the Administrator right or the PQM right can add, modify, or delete
query groups or queries in the Public queries group. However, all users can see the queries in this group,
and can copy and paste them to their own My queries group.
 All queries: Lists all queries that can be seen by the currently logged-in user, based on the user’s scope,
in a flat list (no subgroups). All queries is a composite of the user’s My queries and Public queries groups.
 User queries: (Administrator only) Lists all queries in the core database, organized into subgroups by user.
User subgroups are named with their login IDs (i.e., computername\user account, or domain\user account).
Each user group contains the queries that appear in that user’s My queries group.
Scopes
The Scopes section allows viewing, creating, and editing scopes. Scopes can be used to assign rights.
Reports run for Console Users are scope sensitive.
Configuration
The Configuration section of the tree structure contains the following configuration groups:
 PXE Holding Queue: Lists PXE holding queues and the devices that are waiting in the PXE holding
queue.
 Bare Metal Devices: Lists bare metal devices that have been created for provisioning tasks.
 PXE Provisioning (Windows PE): Lists devices targeted for Microsoft Windows PE provisioning tasks
 Multicast Domain Representatives (Pre 9.6 only): Lists devices configured to be multicast domain
representatives that are pre-9.6 versions only. The latest version uses self-organizing technology and is not
listed in this group.
 PXE Representatives: Lists devices configured as PXE representatives that can deploy OS images to
devices in their subnet.
 Pending unmanaged client deployments: Lists devices that have been discovered by the Unmanaged
Device Discovery (UDD) tool, and are waiting for an agent configuration task to begin.
 User added computers: (Administrator only) Lists devices that have been added to inventory by
Management Suite Console users.
Inspector Results
The Inspector Results section of the tree structure allows you to use the Inspector to view data. You can
double-click a chart in the Inspector window and view the corresponding details. Viewing the results this way
makes the data actionable. (For example, in the Scheduled tasks inspector a chart can show how many
devices have failed a task. If you double-click the chart, you’ll see the individual devices listed in the Inspector
results folder. You can then apply an action to those devices – such as restarting the task, or view a report with
that data for later follow up.)

Data in the Inspector results folder changes every time you double-click on a chart in an inspector window.
Directory
The Directory section shows the Lightweight Directory Access Protocol (LDAP) structure which the Console
User has set (if any). Active Directory access can provide a very effective way to target scheduled tasks.
Layout Menu
The Console allows users to create custom screen layouts with custom columns, based on the task they are
performing, or personal preferences. Different layouts can be configured and saved. The Layout menu is used
to switch between user-configured layouts. The following items are available in Manage Layouts in the Layout
Menu:
 Delete: Deletes the selected layout. (There will be a confirmation to delete.)

 Rename: Lets you change the name of the selected layout.
 Reset: Returns the console window to the previous layout.
 Close: Closes the Manage Window Layouts window.
 Help: Opens Management Suite help.
There is a hands-on exercise for Navigating the Management Suite Console.
Themes
There are 12 themes to choose from that affect the outline colors of the windows in the Consoles. This is a
customization available to each user who can log in to the Console. The theme selections are just below the
toolbar on the Console. Theme choices include:
Silver Pearl Black Pearl Blue Glow Silver Glow Charcoal Grey Retro
Embers Expression Dark Modern Blue Modern Green Modern Orange Steel
There is a hands-on exercise for selecting themes in the Console.
Find
The Find feature appears wherever it makes sense for the user to search for a specific item in a corresponding
list. For example, any time a list of items is displayed in either the upper or lower portion of the Console, the
Find field accompanies that view to facilitate locating a specific item in the corresponding list.
An example of when this can be helpful is if an organization has 10,000 nodes listed in the database. A user
calls for assistance, and the helpdesk team member needs to find the PC in the console. The helpdesk
member can ask for the caller’s login name, or machine name, or any other user and device specific

information, and (as long as the view includes the column with the specific information) the Find can find the
exact entry among the 10,000 entries in a matter of a second or two.
Inventory List
The Inventory List view displays all of the devices that have been added to the Management Suite database.
Items in this list may be sorted by their respective columns by clicking the column header. This view is
displayed by expanding Devices from the Network View and clicking All devices.
Component Window
When a tool is selected from the Toolbox or the Tool menu, a tabbed window appears below the Network View
representing the selected tool. A majority of your work is performed in the Component Window.
Tool Tabs
As additional tools are accessed, tabs are displayed along the bottom of the Console, below the Network View,
providing access to the opened tools. This tabular arrangement makes it easy to have multiple tools open and
navigate among them. This tabular arrangement also supports drag and drop functionality from one tool to
another.
Console Grouping
The majority of the work performed by Management Suite Administrators revolves around Scheduled Tasks
and Distribution Packages. This will be discussed in detail later. For efficient management, scheduled tasks
and distribution packages can be organized into groups.
The following are features for Console groupings for distribution packages and scheduled tasks:
 Subgroups can be added under distribution packages and scheduled tasks

o Distribution packages features for Console groupings:
 My packages can have groups
 Public packages can have groups
 All packages remains a flat list
o Scheduled tasks features for Console groupings:
 Subgroups can be added under scheduled tasks
 Personal folders are blue
 Common folders are yellow

Console Setup Wizards
Wizards are available for five (5) tasks in Management Suite. These wizards proceed through a series of
instructions as the user completes the outlined steps.
Wizards appear automatically on a new installation and can be accessed at any time from the Help menu. You
can follow the steps in the wizard to learn more about the specific feature or functionality. Or you can check the
Don’t show this wizard again check box to prevent the wizard from being shown automatically.
Getting Started Wizard

The Getting Started wizard helps you configure Management Suite to perform the following functions:
 Scheduler: Set the Login account for the Scheduler to use, as well as the account to use when deploying
the Management Suite Agent to unmanaged devices.
 vPro: Configure Intel® vPro™ including General Configuration, ID Generation, Import / Export, System
Defense Remediation, Client Notification Strings, and DVM Configuration.
 COM+: Setup Component Services (to configure login credentials for Active Directory).
Discovering and Installing Agents Wizard

The Discovering and Installing Agents wizard helps you configure Management Suite to perform the following
functions:
 Discover: Setup Unmanaged Device Discovery (UDD) to discover devices to manage using Management
Suite. UDD actively scans the network with industry standard scanning technologies, such as ICMP and
LDAP, for devices that are unknown to Management Suite. IP address ranges can be specified to scan on
the network. IP scans can be set for:
o General IP ranges
o Devices with Management Suite Agent installed
o Devices in an NT Domain
o Devices in an LDAP Domain
o Virtual Hosts (ESX Servers)
 Recurring Discovery: Configure Unmanaged Device Discovery to run on a recurring schedule.
 Deploy Agent: After a device is discovered, the next step is to deploy the Management Suite agent to that
device, making it a Managed Device in the Management Suite Console.
Mobile Device Management Wizard

The Mobile Device Management wizard helps you configure Management Suite to perform the following
functions:
 CSA: Configure the Cloud Services Appliance for mobile device connectivity.
 LDAP: Set up Lightweight Directory Access Protocol server.
 GCM: Configure Google Cloud Messaging.
 APNS: Configure Apple Push Notification Service.
 iSIGN: Configure iOS Profile Signing.
User Management Wizard

The User Management wizard assists you in setting up Role-Based Administration. The wizard helps you
performing the following functions:
 Simple setup: Helps you setup administrators to use the Console with all rights, accessing all scopes.
 Roles: Helps you setup roles to grant which rights Console users will have.
 Scopes: Help you setup which managed devices Console users will see and be able to manage.
 Authentications: Helps you set Roles and Scopes for Console users.

 Users and groups: Helps you set which groups Console users will be in.
 Teams: Helps you set which teams Console users will be in.
Security Updates wizard

The Download Updates tool (as a part of Security and Compliance) assists the user in downloading and
managing security and patch vulnerability definition files from the content servers. The Security Updates
wizard helps you configure the following functions:
 Download Updates: Configure the Download Updates patch tool.
 Schedule Future Downloads: Schedule the Download Updates tool to run periodically.
Launch the Console (Admin Console or Remote

Console)
To start the console:
1. Click Start > LANDESK > LANDESK Management Console. (The actual program name may be
different depending on the Ivanti product that is installed and the license used to activate your Core
Server.)
2. Enter the user name and password. (Enter the user name in the Domain\Username format.)
3. Select the Core Server to which you want to connect. The user must have proper authentication
credentials to that Core Server.
4. Click OK.
The console opens with the layout (size, position, open tool windows, etc.) that was being used the last time
this user logged out.
For additional consoles, the credentials you use to log into Management Suite must match the credentials used
for any drives you have mapped to the core server. Otherwise, you might see a "Multiple connections" error in
the console login dialog.
About the Login Dialog

Use this dialog to launch the console and connect to a Core Server.
 Username: Identifies a Management Suite user. This might be an administrator user or some other type of
user with restricted access (see "Role-based administration overview"). The user must be a member
of one of the LANDESK groups on the core server. Follow the normal Windows rules for remote
login (i.e., if the user is local to that core server, just enter the user name; if the user is a domain
user, enter the domain name\user name).
 Password: The user's password. (NOTE: If a Management Suite Administrator changes the password of
another user, for example an additional console user, the new password does not take effect until that user
reboots their console. At that point, the user would enter the new password to log into the console.)
 Core server: Specifies the Core Server to which you want to connect. This list is the same as the Core
Server list available on the console toolbar.

Fast Views
In version Management Suite 2016, the Console uses virtual list views when selecting items in different tools of
the Console. This means that lists which in previous Management Suite versions took seconds or even
minutes to populate, appear much more quickly in this version! A few places in the console which can have
noticeably large lists include: Device View (netmap), Patch management, and the Query editor. Enjoy the
nearly instantaneous results in the Consoles!
Configure the Network View with Column Sets

The Network View is the foundation of the Console and is always visible. You can customize the Network View
to display the columns of inventory data that are most beneficial to you. Column Sets allow you to customize
the inventory data that displays in the Inventory List pane (to the right of the Network View). Each column in a
column set represents a unique attribute (or component) from the scanned inventory. For example, the default
column set that displays in the Network View is comprised of the Device Name, Type, and OS Name attributes.
Use the Column Set Configuration tool (Tools > Administration > Column Set Configuration) to create as many
Column Sets as you like. To apply a column set, drag the desired column set to device groups and query
objects in the network view tree.
Column Sets Tool

The Column sets tool organizes column sets into three categories:
 My column sets: Column Sets created by the currently logged-in user.

 Public column sets: Column sets created by an administrator, or predefined column sets.
 All column sets: (Only visible to an administrator), column sets created by all Management Suite users.
A user can copy a column set from the Public Column Sets group into their own My Column Sets group and
then modify the column
There is a hands-on exercise for creating a column set configuration.
About the Agent Status Options Dialog

When you open the Console and look at items in the network view, there is an Agent Status Option that affects
both the view and network traffic. The default setting, “For selected visible items only”, in Agent status
options, causes the action of clicking an item in the console to send ping requests. The requests check for the
Management Suite agent, remote control, and HTML remote control. The response packets cause the console
to add icon indicators to the devices in the Console.

Configuring Agent Status Options
To configure Agent Status Options, go to the Console and click, Configure > Agent status options.
Use this dialog to configure the following agent discovery options.
 Gather agent status:

o Never: Never gather the agent status. This sets so no ping requests are sent to devices by use of the
console. Use this option if you have a slow network or saturated network links.
o For selected visible items only: Specifies that a device's agent status is updated as the device is
selected in the network view. This sends out ping requests to the device selected.
o For all visible items: Specifies that all visible devices in the network view will have their agent status
updated according to the refresh rate. As new devices become visible, their agent status (and health)
are updated. This option generates the most network traffic.
 Use DNS: This setting is for changing the priority of the IP address in the database with the address for the
item in DNS. When remotely controlling a device, for instance, if the DNS entry for the device differs from
the address in the database, the remote control command will be sent to the device IP address listed in the
DNS entry rather than the entry in the Management Suite database.
 Refresh every < > minutes: Indicates whether agent status is automatically updated at the interval you
select. To enable this option, select the box beside Refresh. This option is disabled by default, and the
refresh interval only applies if the option's box is checked. If you enable this, consider using the default 5-
minute interval or longer to reduce the amount of network traffic.
Web Console Navigation Basics

The Web Console is accessed from an internet browser window from anywhere on the network by browsing to
http://<CoreServerName>/remote.

(The defined portions of the Web Console have the same usage and nomenclature as has been previously
defined in the Remote Console section earlier in this module.)
Note: The Student Exercise Guide includes how to navigate the Console, and how to add tools to the
Favorites tool group.
Configuring Role-Based Administration

Role-Based Administration Overview
Administration of Management Suite is based on roles assigned to users, based on their job requirements.
Roles can be created and assigned to Desktop Support personnel at different levels, based on what they need
to do perform their job. Management Suite provides an extensive set of Role-Based features, including:
 Granular feature-based group permissions

 Permissions for multiple users through local or LDAP user groups
 Console User configurations synchronized across multiple Core Servers
Role-based administration is flexible enough to let you create as many custom roles as you need. You can
assign the same limited permissions to different users but restrict their access to a limited set of devices with a
narrow scope. Even a Management Suite Administrator can be restricted by scope, essentially making them an
administrator over a specific geographic region or type of managed device. How you take advantage of role-
based administration depends on your network and staffing resources, as well as your particular needs.
For more information on using Role-Based Administration, see the following sections:
 Adding Management Suite console users
 Managing authentications
 Managing roles
 Understanding rights and states
 Creating scopes
 Using teams

Role-Based Administration Workflow
The following is the basic process for using Role-Based Administration:
1. Import Console Users.

2. Create roles for Console Users.
3. Use the Windows Local Users and Groups tool to add Console Users to the appropriate Windows
Management Suite groups.
4. Create authentications for each Active Directory you will be using to designate Console Users.
5. Optionally use scopes to limit the list of devices that Console Users can manage.
6. Optionally use teams to further categorize Console Users.
The “User Management” Wizard walks Management Suite Administrators through the necessary steps to fully
implement Role-Based Administration.
Adding Management Suite Console Users

Management Suite users can log in to the console and perform specific tasks for specific devices on the
network. The user that is logged in to the server during Management Suite installation is automatically placed
into the Windows LANDESK Administrators user group, which gives them full administrator permissions. This
individual is responsible for adding additional groups of users to the console and assigning permissions and
scopes. Once other administrators have been created, they can perform the same administrative tasks.
Management Suite setup creates two (2) local Windows groups on the core server. These groups control file
system permissions to the Management Suite program folders on the core server. You must manually add
console users to one of these local Windows groups:
 LANDESK Administrators: This is the failsafe group for console access. Anyone in this group has full rights
in the console, including script writing. By default, the user account that installed Management Suite is
added to this group. If you don't have many console users or you don't want to limit the console users that
you do have, you can bypass role-based administration entirely and just add users to this group.
 LANDESK Management Suite: This group allows basic core access. The Management Suite folders are
read-only. Users in this group can't write to the scripts directory, so they won't be able to manage scripts.
Patching vulnerabilities and OS deployment won't work correctly for users in this group because both those
features use scripts.
When adding full administrators to the console, you can either add them to the core server's local LANDESK
Administrators group or you can add them to a different group that has the LANDESK "Administrator" right.
The only difference is that users in the Windows LANDESK Administrators group can't be deleted from the
console until they are removed from the LANDESK Administrators group.
The Users tool's Users and groups tree shows the list of authorized console users. You can see the last time a
console user logged in, their group, role, scope, remote control time restriction status, and team. You can also
use this tree to see if users are in the local Windows groups. Users won't be able to log in until you've added
them to one of the LANDESK groups described in this section.
Users are stored in the database by unique security IDs (SIDs). If a user's active directory account name
changes, for example changing a name to include a married name, their SID should remain the same and their
Management Suite permissions will still apply.
IMPORTANT: Additional consoles and the core server must be members of the same domain or workgroup.
Console users won't be able to authenticate with a core server that is in a different domain or workgroup.

To add users to a LANDESK group from the Windows Computer Management dialog box
1. Navigate to the server's Administrative Tools > Computer Management > Local Users and Groups >
Groups utility.
2. Right-click the LANDESK group you want, and then click Add to group.
3. In the group's Properties dialog box, click Add.
4. In the Select the users and groups dialog box, select the desired users (and groups) from the list and click
Add.
5. Click OK.
To add a Management Suite console user or group
1. Click Tools > Administration > User management.

2. Expand the Users and groups tree.
3. Right-click the authentication source containing the user or group you want, and click New user or group.
(The Add users and groups window opens.)
4. Select the user or group you want to add and click Add. If you want to select individual users within a
group, right-click the group and click Select users to add. You can then select the users you want and
click Add selected users.
5. In the dialog box reminding you to manually add the user or group you selected to the appropriate local
Windows group, click OK.
6. Click Close.
7. If you haven't already, use the Windows Local Users and Groups tool to add the new user or group to the
appropriate local Windows group as described earlier in this section.
8. Assign roles and scopes to the new user or group.
Delete Users
You can also use the Users and groups tree to delete console users or groups. When you delete Users or
groups, assigned to access console resources, such as queries, scheduled tasks, and so on, the console will
automatically delete any items they own or reassign items they own to another user or group that you select.
Note that deleting a user or group only deletes that user or group from the Management Suite user database.
Manually remove the user or group from local Windows groups they are members of. If you don't do this, the
deleted user will still be able to log into the console.
To delete a console user
1. Click Tools > Administration > User management.

2. In the Users management tree, click Users and groups.
3. Select the user or group you want to delete and press the Delete key.
4. If you want to delete objects associated with the user, click OK.
5. If you want to reassign objects associated with the console user, select Assign objects to the following
user/group or team and click the user, group, or team you want to receive the objects and click OK.
6. Remove the user from the local Windows group or Active Directory group that gives them console access.
Viewing User or Group Properties

In the Users and groups tree, you can right-click a user or group in the right pane and click Properties.

This properties dialog box shows all the properties and effective rights for that user. The properties dialog box
has the following pages:
 Summary: Summarizes that user's/group's roles, scopes, teams, group membership, and effective rights.
 Effective rights: Shows a more detailed view of the user's/group's effective rights.
 Roles: Shows explicit and inherited roles. You can select which explicit roles apply to that user or group.
 Scopes: Shows explicit and inherited scopes. You can select which explicit scopes apply to that user or
group.
 Teams: Shows explicit and inherited teams. You can select which explicit teams apply to that user or
group.
 RC time restrictions: Allows you to apply and modify RC time restrictions. For more information, see "Using
remote control time restrictions".
 Group membership: Shows which groups that user is a member of.
If you make changes to the editable pages, you need to click OK to apply them. You can then re-open the
properties dialog box if necessary.
Managing Authentications
The User management tool can be configured to assign Console access via Active Directory groups. To do this
you will need to provide credentials for each Active Directory container having users you want to grant Console
access. The authentications you provide determine which user groups you can select from the User
management tool to assign Console group permissions.
Console authentication is based on Windows local or Active Directory group membership. When a
Management Suite administrator assigns group permissions to a local or Active Directory group, users who are

members of that group can log into the Windows or Web consoles and share the permissions assigned to that
group.
You should be aware of the following issues when managing Active Directories for use with Management
Suite:
 Active Directory is fully integrated with DNS and TCP/IP (DNS) is required. To be fully functional, the DNS
server must support SRV resource records or service records.
 In order to log in to the Console, a user must belong to the core server's local groups. For more
information, see "Adding Management Suite console users".
 In order for an AD Domain to work properly with Role-Based Administration, you need to configure the
COM+ server credentials on the Core Server. This enables the Core Server to use an account in one of the
core server's local groups that has the necessary permissions to enumerate Windows domain members,
such as the administrator account. Some excellent resources on how to configure COM+ please see:
o “Configuration, “Configuring COM+ Server Credentials” at:

o “How to Configure the LANDESK COM+ Application to use a Domain Account” at:
If a user account password changes, you will have to log into the console and change the password in the
authentication dialog box to the new password. You can do this by logging in as a local group. Users are
authenticated when they log in, so any existing session will continue to work. Users in the domain that have
had the password changed won't be allowed to log in until the password change has been corrected in the
Users tool.
Setting Rights with Active Directory

The following rules apply to when using Active Directory with Role-Based Administration (RBA):
 If a user is a member of an Active Directory group, the user inherits the RBA rights for that group.
 If a user is a member of an Active Directory group, which is a member of a higher level group, the user
inherits the RBA rights of the upper level group.
 Groups can be nested and inherit the appropriate rights according to the usual Active Directory rules.
Add an Active Directory Authentication Source

Use the User management tool to define credentials for Active Directory groups that will have console access.
These credentials only need to let Management Suite enumerate the directory. You'll need to provide
credentials for each Active Directory containing users you want to have console access. The authentications
you provide determine which user groups you can select from when assigning console group permissions.
To add an authentication
1. In the Network View, right-click Directory, and click Manage Directory. (The Active Directory source
window opens.)
2. Click [Add], and enter the LDAP source, authentication User name and Password credentials that grant
access to the Active Directory.
3. Click [OK].

Managing Roles
Use the Roles tree to define and maintain administrative roles and associated console rights. Console rights
are based on Management Suite features. For example, you can create a help desk role and give it the remote
control right.
You can add as many additional roles as you need. New roles aren't automatically assigned to any users or
groups. Once you create a role, you associate it with a user or group in the Group Permissions tree.
Since you can assign multiple roles to users or groups, decide how you want to assign rights. You can either
assign rights based on a job description, such as "help desk," or you can assign rights based on console
feature, like "remote control." Depending on the number and variety of console users your organization may
have, one way may work better than the other.
You can assign multiple roles to a user or Active Directory group. If there are conflicting rights among the
selected roles, the group permission consists of the sum of the combined roles and scopes. For example, if
one included role allows remote control and another included role denies it, the resulting group permission will
allow remote control. You can see the effective rights for a user or group by opening the properties for it and
viewing the Effective rights page.
Generally, you should avoid assigning a role to the default local groups: LANDesk Management Suite, and
LANDesk Administrators. Assigning a role to a group affects everyone in the group. Since all console users
must be a member of one of these three groups, you could unintentionally restrict everyone's access to
console features. The LANDESK Administrators group already has a default role of Administrator, which you
can't restrict further.
Changes to a logged-in user's rights won't take effect until the next time they log in.
Create and Assign a Role

Use roles to define and maintain administrative roles and their associated console rights.
To create and assign a role
1. In the User management tool, right-click Roles and click New role.
2. In the Role properties dialog box, enter a role Name.
3. Enable or disable the rights you want by clicking on the symbol in the appropriate column. Each click
toggles the right's state.
4. In the tree click Users and groups and select the users and groups that will have the new role.
To assign an existing role to users and groups
1. In the User management tool, right-click Roles and click Properties. You can also double-click a role to edit
its properties.
2. On the Users and groups page, select the groups you want to have that role.
3. Click OK.
Understanding the Default Roles

There are a number of default roles under the Roles tree. You can edit or delete any of these default roles.
 Auditing Configuration
 Auditor
 Data Analytics Administrators

 Inspector Viewer
 IT Help Desk
 LANDESK Administrator
 Patch Management
 Power Management
 Provisioning
 Security
 Software Distribution
 Software Licensing
LANDESK Administrators have full rights to all scopes and rights. They also have full access to the Users tool
and can make any changes they want. Only users with the Administrator right can configure LANDESK
services running on the core. If Auditing is desired, add the rights of Auditing permission to the LANDESK
Administrators group.
Understanding Rights
There are four types of rights a user can have:
 View: Allows users to access a console tool.

 Edit: Allows users to make changes in the associated console tool. Includes the view right.
 Deploy: Allows users to create, modify, or delete any scheduled tasks associated with the associated
console tool.
 Edit public: Allows users to create, modify, or delete items in a console tool's Public folder.

Not all rights support all types. For example, the "Public query management" right can only have the "Edit
public" type. It wouldn't make sense to also have the "View," "Edit," or "Deploy" types.
There are three states a right can have:
A checkmark:
An X:
A not applicable symbol:
Clicking on a checkmark or an X will toggle its state.
If users have no rights for a tool, they won't see the tool when they log into the console. The tool won't appear
in the Toolbox or in the Tools menu.
The Scheduled tasks tool is only visible to users who have a "Deploy" right, and in that case, they can only
work with tasks associated with the tool they have deploy rights for. All other tasks are read-only.
Creating Scopes
A scope defines the devices that can be viewed and managed by a Management Suite user.
A scope can be as large or small as you want, encompassing all of the managed devices scanned into a Core
database, or possibly just a single device. This flexibility, combined with modularized tool access, is what
makes role-based administration such a versatile management feature.
Default Scopes
Management Suite's Role-Based Administration includes one default scope: "All machines." This scope
includes all managed devices in the database. You can't edit or remove the default scope.
Custom Scopes
There are three types of custom scopes you can create and assign to users:
 LDMS Query: Controls access to only those devices that match a custom query search. You can select an
existing query or create new queries from the Scope properties dialog box to define a scope. Note that you
can also copy queries from the Queries groups in the network view directly into the Scopes group.
 LDAP: Controls access to only those devices gathered by the inventory scanner that are located in an
LDAP-compliant directory structure. Select directory locations from the Select visible devices dialog box to
define a scope. This directory-based scope type also supports custom directory locations (if you've entered
custom directory paths as part of an agent configuration). Available custom directory paths appear in the
Select visible devices dialog box. Use custom directories to define a scope if you don't have an LDAP-
compliant structure, or if you want to be able to restrict access to devices by a specific organizational detail
such as geographic location or department.
 Device Group: Controls access to only those devices that belong to a specific device group in the network
view.
A Management Suite user can be assigned one or more scopes at a time. Additionally, a scope can be
associated with multiple users.
How Multiple Scopes Work

More than one scope can be assigned to any of the Management Suite users. When multiple scopes are
assigned to a user, the user has rights to all computers in all assigned scopes. The cumulative list of
computers in all assigned scopes is the user's effective scope.

A user’s effective scope can be customized by adding and removing scopes at any time. Multiple scopes and
scope types can be used together.
A user’s rights and scopes can be modified at any time. If you modify a user’s rights or scopes, those changes
take effect the next time that user logs into the Console or when a Console administrator clicks the Refresh
scope toolbar button on the Console (top of window).
Create a Scope
A scope defines the devices that can be viewed and managed by a Management Suite Console user. A scope
can be as large or small as you want, encompassing all of the managed devices scanned into a core database,
or possibly just a single device.
There are two places in the Console to create Scopes:

1. In Network View > Scopes
2. In User Management > Scopes
To create a scope
1. Click to select Scopes in either Network View or User Management.

2. Right-click Scopes and click New Scope.
3. In the Scope Properties dialog box, enter a name for the new scope.
4. Specify the type of scope you want to create (LDMS query, LDAP or custom directory, or device group) by
clicking a scope type from the drop-down list, and then clicking New.
5. If you're creating an LDMS query-based scope, define the query in the New scope query dialog box, and
then click OK.
6. If you're creating a directory-based scope, select locations (LDAP directory and/or custom directory) from
the Select visible devices list (you can browse the directory by clicking Browse directories), and then click
OK.
Click on the plus (+) and minus (-) signs to expand and collapse nodes in the directory tree. All nodes under a
selected parent node will be included in the scope.
LDAP directory locations are determined by a device's directory service location. Custom directory locations
are determined by a device's computer location attribute in the inventory database. This attribute is defined
during device agent configuration.
7. If you're creating a device group-based scope, select a group from the available device group list, and then
click OK.
8. Click OK again to save the scope and close the dialog box.
To create a scope based on an existing query
1. Right-click Scopes and click New scope from query.

2. Select the query you want and click OK.
3. A copy of the query will be made and a new scope appears in the tree with a name based on the source
query name.
About the Scope Properties Dialog Box

Use this dialog box to create or edit a scope. You can access this dialog box by selecting a scope and clicking
the Edit scope toolbar button or by right-clicking the scope and then clicking Properties.

 Scope name: Identifies the scope.
 Select a scope type:
o LDMS query: Creates a scope whose device range is determined by a custom query. Clicking New
with this scope type selected opens the New query dialog box where you can define and save a
query. This is the same query dialog box you use when creating a database query from the network
view. (Note that you can also copy queries from the Queries groups in the network view directly into
the Scopes group.)
o LDAP: Creates a scope whose device range is determined by the device location (LDAP directory
and/or custom directory). Clicking New with this scope type selected opens the Select visible
devices dialog box where you can select locations from inventory data. Click on the plus (+) and
minus (-) signs to expand and collapse nodes in the directory tree. You can multi-select locations by
using Ctrl+click. All nodes under a selected parent node will be included in the scope. If you click
Browse directories, you can browse and select devices from the actual LDAP directory tree for
directories you've configured.
o Device group: Creates a scope whose device range is determined by an existing group of devices
contained under the Devices object in the network view. Clicking New with this scope type selected
opens the Query filter dialog box where you can select a device group.
 Current scope definition: Displays the query statements for a query-based scope, the location paths for a
directory-based scope, or the group name for a device group-based scope.
 Edit: Opens the scope's appropriate dialog box where you can change query parameters and statements.
Using Teams
A role-based administration team is a group of users that can view and share ownership of tasks and
configurations that belong to the team. For example, if you have multiple departments that want to share
queries or tasks, you can group the departments into a team. A team's tasks and configurations appear in a
special group named after the team in a tool's tree view. For example, if you have a team named "New York"
that you are a member of, you would see a “‘New York’ devices" subgroup under the Devices group in the
Network view. People can belong to multiple teams.
People who aren't in a particular team won't see that team's group anywhere in the console. People with the
administrator right see all teams and team content. While you can use public folders to share console content,

public folder content is visible to everyone with rights to a tool. The advantage with teams is that only team
members see team content, potentially making content more organized and accessible to team members.
Teams consist of one or more group permissions. You can even create teams with as few as 1 or 2 people.
For example, if a person is out sick, you can add that person's substitute to the same team. Or, if you have two
people that share responsibilities, you can put them in the same team.
Administrators and team members can change the ownership of tree items by right-clicking them and clicking
Info. Information dialog boxes have an Owner drop-down list where you can select the item's owner.
Create a Team
A role-based administration team is a group of users that can view and share ownership of tasks and
configurations that belong to the team. A team can view management items (Device Groups, Queries,
Configurations, etc.) only visible to members of the team and member of the LANDESK Administrators group
on the Core Server.
To create a team
1. In the User management tool, right-click Teams and click New team.
2. Enter a team Name.
3. Select the Users and Groups that you want in the team.
4. Click OK.
There is a hands-on exercise for implementing role-based administration.
Using Remote Control Time Restrictions

Remote control time constraints limit the hours and days console users can initiate remote control sessions.
You can specify the days of the week and the starting and ending time (in UTC format) that you want to allow
remote control.
Note that the starting time is in UTC (Coordinated Universal Time or Greenwich Mean Time) format. The core
server determines the starting time by checking the UTC time reported by the core server's operating system.
The core server doesn't adjust for the console users' local time zone. When entering the starting time value,
you need to compensate for the difference between UTC time and the console operators' local time zone and
use the resulting adjusted time.
By default no remote control time restrictions are active.
Note that RBA rights are additive. If a user is a member of multiple roles, you could unintentionally allow
remote control when you intended to restrict it. For example, if a user is a member of a remote control role that
includes time restrictions and that user is also a member of a security role that doesn't include time restrictions,
that user won't have any remote control time restrictions.
To ensure remote control time constrictions are applied in the way you intend, you may want to make sure
users with time restrictions have only one role applied to them.
Assign remote control time restrictions

Remote control time constraints limit the hours and days console users can initiate Remote Control session.
These are applied to Console Users or Groups.

To use remote control time restrictions
1. In the User management tool (Tools > Administration > User management), right click a user or group
in the Users and groups tree and click Properties.
2. In the left pane click RC time restrictions.
3. Check Use time constraints.
4. Check the days you want enabled.
5. Enter the time range that you want to allow remote control.
6. Click OK when done.
There are exercises for implementing Role-Based Administration in the Student Guide.
Scheduled Tasks
At the very heart of centralized management and managing devices throughout the enterprise is the ability to
Schedule Tasks from a Console. All centralized management begins with seeing the complete list of managed
devices, and acting upon them from the Console. Whether the need is to remotely control a device, distribute
software to a device, apply updates and patches to a device, or other actions which might need to be run on a
managed device, the key to central management is acting upon managed devices in the Console.
To enhance the ability of the Console users, when scheduling tasks, Management Suite has added
functionality to the Scheduled Tasks tool.
When initializing Scheduled Tasks, the task is right-clicked, and Start now is selected. The options presented
are:

 All -- to start all devices in a task
 Devices that did not succeed -- devices in pending, failed, or active
 Devices that did not try to run the task -- devices in pending
 Waiting or currently working -- devices in pending or active
These options allow strategic scheduling based on needs.
Active Directory Targeting

A new and helpful feature available in Management Suite 2016 is the ability to leverage Active Directory (AD)
gathering when a device is accessed via the Cloud Services Appliance (CSA). If AD information is not
available concerning a managed device, it will connect via the CSA and a web service on the Core Server will
resolve the LDAP information and return it to the task, allowing AD targeting in tasks.
Diagnostics
In version Management Suite 2016, Diagnostics have been significantly enhanced. To pull up the Diagnostics
window, right-click on a managed device in the Console’s device view, and select “Diagnostics”.
The Diagnostics window is divided into two parts. The top portion lists each scheduled task assigned to the
managed device. Above that is the toolbar. The toolbar opens a plentiful array of options.
There are numerous other options in the Diagnostics Tool. A great way to see the options open Diagnostics on
a device and right-click a listed task. This will bring up the options.

Or, optionally, you can launch the same tools from the Diagnostics toolbar.
Diagnostics is a helpful, useful, wonderful all-around tool to diagnose all tasks pertaining to a managed device.
(We will use Diagnostics in a hands-on way when we have created some tasks in the Software Distribution
section.)
Diagnostics Toolbar
The first option in the Diagnostics toolbar, , Logs, presents options to view logs which might be
contained on either the Client, or the Core. If you select one of the many logs presented, the tool retrieves the
associated log and displays it in the bottom portion of the window. Gone are the days of searching directories
for logs, finding them in droves, and endlessly searching to find the exact log associated with an exact task!
Diagnostics can retrieve the file contents, regardless of whether the log is locally or the client device, or on the
Core Server.
An option available in Logs > Client is the option to “Get all and zip”, which will pull all client and core logs
related to the selected task and store them in a location you select. Another option in the same screen is “Get
SCAP reports” (SCAP means Secure Content Automation Protocol) which is available in Java™ SE
Development Kit 8, Update 60 (JDK 8u60) and above.
The second option in the Diagnostics toolbar, , Real-time discovery, presents a window which populates
with a variety of information about the device, including the fully qualified name, IP address, Subnet mask,
MAC address, Discovery type, Port, Device ID and Discovery response XML information.

The third option in the Diagnostics toolbar, , Inventory, brings up the complete inventory of the device.
This will contain data as current as the last inventory scan of the device. (This is the same inventory you would
see if you were to right-click a device and select Inventory.)
The fourth option in the Diagnostics toolbar, , HTML5 Remote control, opens a session of remote control
with the device.
The fifth option in the Diagnostics toolbar, , View task client policy, brings up the task client policies
assigned to the device.
The sixth option in the Diagnostics toolbar, , View Security and Patch information, brings up an
interactive window of all the security and patch information concerning the device.
The seventh option in the Diagnostics toolbar, , Client inventory change history, brings up the inventory
change history of the device. You can show the log file in an external viewer by clicking the [External] button. If
the file is larger than 50K bytes, you can click the [Truncated] button, which will bring up the last 50K bytes in
the results pane of the window.
The eighth option in the Diagnostics toolbar, , Client task history, bring up the contents of the task history
in the device’s TaskHistory.xml file.
The ninth option in the Diagnostics toolbar, , Enable remote file system access, sets the device so that if
you select Remote file system the file system is accessible.
The tenth option in the Diagnostics toolbar, , Remote event viewer, brings up the interactive event viewer
of the device.
The eleventh option in the Diagnostics toolbar, , Remote file system, brings up the interactive file system
of the device.
The twelfth option in the Diagnostics toolbar, , Synchronize policies, launches PolicySync.exe on the
device.
The thirteenth option in the Diagnostics toolbar, , Re-run task on selected device, allows you to select a
task in the top window, then click to select this option, to re-run the task.
The fourteenth option in the Diagnostics toolbar, , Terminate process, brings up a window where you can
enter the Process ID, click the [OK] button, and the corresponding process will terminate.
The fifteenth option in the Diagnostics toolbar, , View local scheduler tasks, brings up the list of items in
the local scheduler of the device. These items populate based on the Management Suite Agent installed on the
device.
The sixteenth option in the Diagnostics toolbar, , View running processes, brings up a list of running
processes on the device. The list contains the process name, process ID and the amount of memory the
process is currently using. The LANDESK processes are highlighted.

The seventeenth option in the Diagnostics toolbar, , View services, brings up a list of the services of the
device. The list contains the name, description, and status of the services.
The eighteenth option in the Diagnostics toolbar, , Search Ivanti Community web site, brings up a
window where you can enter search criteria to be sought for on the Ivanti Community web site.
The nineteenth option in the Diagnostics toolbar, , Search the web for highlighted log file text or the
current error code (F3), brings up the default browser. In the browser window, the search of the current error
code, or the highlighted text (if you have highlighted text), is searched for using the default search engine
designated in the browser.
The twentieth option in the Diagnostic Toolbar, , Find, allows you to type
what to search for in the columns of the Diagnostics tool. You can designate to search in any column, or you
can select in a specific column.
The Export to csv button, , on the Diagnostics toolbar, allows you to export to a .csv file, the information
pulled up in the diagnostics tool.
The Reset column order button, , on the Diagnostics toolbar, resets the order of columns in the
diagnostics tool to the original order in which they first appeared when the installation occurred.
The Refresh button, , refreshes the view in the diagnostics tool.
We will do a hands-on exercise using the Diagnostics tool after we have deployed software, later in the
course.
IPv6 Communication
Ivanti recommends that both IPv4 and IPv6 be enabled on both the Core Server and managed devices. The
managed devices use IPv4 for internal communication. The managed devices use IPv6 (using Proxyhost.exe)
to communicate with web services on the Core Server. The Core Server uses IPv4 to initiate communication
with the managed devices. The Core Server uses IPv4 for name resolution and discovery. The Core Server
supports using IPv6 for web services.

Credant™ Integration
Credant™ has solutions to protecting data on the hard drive, including products encrypting the hard drive.
Ivanti has partnered with Credant to report in the Management Suite tools Credant information, including
additional data to Inventory, Reporting, and Patch and Compliance. Additionally, there is ability to open the
Web Console of the Credant server from the Console.
Credant Architecture
There are three types of servers used in the Credant Security solution. There are:
 Policy Server: The Credant server which places and enforces security policies.
 Gateway Server: The Credant server which direct sending and receiving information between the Credant
servers and managed devices.
 Reporting Server: The Credant server housing data for reporting purposes.
These servers are often combined in one for fewer managed nodes, but in larger enterprise scenarios, they
can be separated for utilization reasons.
Management Suite has the ability to gather Credant Shield information from the Credant database, and place
the data in the Management Suite database. This enables additional Inventory, Queries, and Reporting. This
synchronization can be done with one or many Credant databases.
Management Suite Integration with Credant

The Console provides configuration settings to connect with Credant servers, synchronize data to the
Management Suite database, and then make that data available in Inventory, Reporting, and Queries.
The Steps for Integrating with Credant database(s) include:

1. Add the Credant Servers to Patch and Compliance: This sets servers and connection information.
2. Schedule Synchronization from the Credant database(s) to the Management Suite database: This
brings the data into the Management Suite database, making it available to Inventory, Queries, and
Reporting.
Add Credant Servers to Patch and Compliance

Steps to add Credant servers to Patch and Compliance are as follows:
1. On the Console, click Tools > Security and Compliance > Data protection. (This opens the Data
Protection tool in the bottom pane of the Console.)
2. Click the Configure or Add Credant servers icon on the Data Protection toolbar.
3. Enter the appropriate Credant Server and connection information. (Of significant note is the automatic
checking which verifies connectivity immediately when this information is entered, which minimizes efforts
to troubleshoot.)
When Credant server(s) are added, the columns to the right of the server show the status and messages of the
synchronization. This greatly reduces the need for troubleshooting, and is an indicator that the data is up to
date.
Schedule Synchronization of Credant Servers to Management Suite Database

Steps to schedule synchronization of Credant servers to the Management Suite database are as follows:
1. In the Console, click Tools > Security and Compliance > Data protection. (This opens the Data

2. Click the Schedule Credant server integration icon on the Data Protection toolbar. (This opens the
Scheduled Task tool with the task set up for scheduling.
3. Schedule the Start time and frequency of update.
Credant Information Included in the Managed Device Inventory

When synchronization has occurred, additional information is available in a managed device’s inventory.
To access the inventory do the following:

1. In the network view of the Console, Right-click on the Managed Device.
2. Click to select Security > Data Protection. (The Data Protection data is displayed.)
The Data Protection data includes:
 DCID – A unique device identifier used by Credant.
 Gatekeeper Name – The name of the Credant Gateway Server.
 Installed (True, False) – Whether the Credant protection installed.
 Last Sync Time – Last time managed device data was pulled from the Credant database.
 MCID (Credant ID) – A Credant identifier.
 Product Name – The name of the Credant product (e.g. Mobile Guardian).
 Product Version – The version of the Credant product.
 Protected Date – The data encryption was performed (blank if not encrypted).
 Server name – The name of the Credant Policy server.
 Service Status – The status of Credant product.
Reporting the Credant Data

With the additional data in the Management Suite database, Queries can pull the Credant information. The
column sets can also include Credant data, so the network view can display the additional data.
There is also a new report that is included, which shows the Credant data. In the Reporting tool, you can find
the Data Protection Report. The report can include which Credant products to include in the report, which
managed devices to include, and which Credant servers to include. The report shows the following:
 Credant Device Summary – Displays a graph showing the Credant devices.
 Credant Protected State – Displays a graph showing the percentage of devices in a Credant protected
state.
 Credant Agent Version – Displays a graph showing the Credant Agent version.
Columns in the report include the Device Name, the Data Protection Client Product, the Date Protect Client
Version, and the Protected Date.
Launch the Credant Web Console

The ability to launch the Credant Web Console is included in the Data Protection tool.
To launch the Credant Web console do the following:

1. In the Console, click Tools > Security and Compliance > Data protection. (This opens the Data
2. Click the Credant Web Console icon on the Data Protection toolbar.

Consoles Check for Understanding
1. What Single Sign-on options are available to log in to the Management Suite Consoles?
2. What effect do Themes have in the Consoles?
3. What effect does Fast Views have in the Consoles?
4. How does implementing Role-Based Administration improve management functionality in Management

Suite?
5. How can Diagnostics help troubleshoot failed scheduled tasks and policies?
6. What impact does Active Directory Targeting have on a device that connects via the Cloud Services
Appliance?
7. What impact does IPv6 communication for the Core Server, Consoles, and Managed Devices?

Agents
Module Objectives
In this Agents section you will:
 List the Supported Clients for Management Suite 2016

 Describe how Client-Side Certificate functionality is implemented
 Outline the Enhanced Macintosh Support
 Describe non-persistent Virtual Desktop Support
 Make an Unmanaged Device Managed
 Describe how Discovery Works
 Describe how Client self-electing processes work
 Learn how self-electing subnet services work
 Create Agent Settings
 Create Management Suite Agent Configurations
 Deploy the Agent Using the Advance Agent Method
 Install the Management Suite Agent using the Pull Method
 Schedule Deployment of the Management Suite Agent
 Create a Stand-alone Management Suite Agent Configuration Package
 Tell how to Uninstall the Management Suite Agent
 Update Management Suite Agent Settings on a Managed Device
 Describe how Management Suite Manages Mobility Devices
 Configure a Management Suite Agent for Macintosh Devices
 Configure a Management Suite Agent for Linux and UNIX Devices
 Implement Agent Health
 List the Agent Watcher Settings
 Troubleshoot the Agent Installation

Agents Overview
Management Suite uses agent configurations, created by the Management Suite Administrator, to deploy
agents, with their accompanying preferences, to managed devices. Once devices are configured with the
Management Suite Agent, they are fully manageable via the functional and productive tools of the
Management Suite Console.
The Agent configuration tool enables you to create new agent configurations for:
 Windows Workstations
 Windows Servers
 Windows Embedded devices
 Macintosh devices
 Linux devices
 HPUX devices
 Solaris devices
 HP ThinPro Linux devices
o Windows Embedded Standard 7 Enterprise (WES7)
o Windows Embedded Standard 09 Enterprise (WES09)
 AIX devices
The agent configurations you create can then be pushed to Windows and Macintosh devices using the
console's Scheduled tasks window, logon scripts, or by group policy objects.
The Agent settings tool enables you to create settings that can be deployed as scheduled tasks to managed
devices. This enables scheduling setting changes that are very small in size, when compared to deploying the
entire agent again. This saves time and bandwidth when configuring managed devices to have different
settings.
Supported Managed Devices in Management Suite version 2016

Management Suite 2016 supports many devices with various Operating Systems. In the Windows
world, there is support for Windows™ 10, 8.1, 8, 7, and Microsoft® Windows™ Server 2012 R2. In
the Macintosh world, there is now support for Yosemite 10.10.5, Maverick 10.9.5, and Mountain Lion
10.8.5. For a complete list of supported Operating Systems, please go to the Community Web Site
and look at: http://community.ivanti.com/support/docs/DOC-23848.
Client-Side Certificates
In versions previous to Management Suite 2016 security assured was enforced by a certificate if a device
connected via the Cloud Services Appliance (CSA) or by the public and private key set used by Public Key
Infrastructure (PKI) technology. This enforced whether a managed device trusted management from the Core
Server. In Management Suite 2016, additional security is implemented centered on the premise that the Core
Server does not have to trust a device just because it has a Management Suite Agent. Each client now
generates a certificate, and the Core Server has ability to allow whether to manage the device, based on the
certificate.
Architecture
Architecture includes pieces on the Managed Device and the Core Server.

Architecture - Managed Device
Client-side certificates are generated by running BrokerConfig.exe /n. (The Management Suite Agent places
the command in the local scheduler and sets it to run once each day.) This action checks to see if there is a
client-side certificate already generated. If there is, it does not generate a new certificate. If there is not a
certificate already generated, it will generate one. Client-side certificates are stored locally in the directory:
C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker. The files in the directory include:
 broker.key: This is the private key and should be protected.
 broker.csr: This is the certificate signing request which is sent to the core to be approved.
 broker.crt: This is the public key in X509 certificate format.
 proxy.state.xml: This file contains the timestamp and the originating IP Address.
The log of the activity of creating the certificate is located at

C:\ProgramData\LANDesk\Log\BrokerConfig.log
When BrokerConfig.exe makes a request to have a new public certificate signed, it makes a web request to the
core server at the following URL:
http://corename/landesk/managementsuite/core/core.anonymous/ClientCertificateRequest.asmx
Architecture - Core Server

Certificates the Core Server receives from the client are listed in the Client Access tool. There, the
Management Suite Administrator can approve or block the certificates. To access the Client Access tool, open
the Management Suite Console and click Configure > Client Access.
By default, new certificates listed are assigned the Unapproved state. This means the Management Suite
Administrator will have to periodically open the Client Access tool and approve certificates, by selecting
certificates in the list and clicking the [Approve selected] button. If you are in the process of performing a

rollout or upgrade, you can select the Automatically approve new certificates (not recommended)
checkbox, for a time, and the new certificates will be automatically approved.
Certificate States Defined
Client Access Tool Navigation
Unapproved/Approved/Blocked/Created by Provisioning: These are filters. If all four are selected, then all
devices in the database are shown. By default, only the unapproved checkbox is selected to show the
Management Suite Administrator the list needing to be approved.
Exclude devices with inventory data: Selecting this checkbox will remove all devices from the list with inventory
in the Management Suite database. The remaining items in the list would be devices that have not been able
to report inventory data because they have not yet been approved.
Approve selected: Select one or more devices in the view and click this button to approve them.
Block selected: Select one or more devices in the view and click this button to block them.
Delete selected: Select one or more devices in the view and click this button to delete them from the database.
These devices will need to request to have a new client-side certificate signed by the core before they can
operate through the CSA.

Delete all blocked: Selecting this checkbox will remove all blocked items from the database. Management
Suite Administrators may choose to do this from time-to-time to clean up the database. Deleting blocked items
does not change the behavior of those devices.
Items per page: Sets how many certificates listed in the view to include per page.
Automatically approve new client certificates (not recommended): While not recommended, it is believed that
some customers may want to make it as easy as possible to get new devices enrolled for a short time while
enrolling lots of machines such as during a rollout or upgrade. Selecting this checkbox will automatically
approve all new devices when their client-side certificate is generated. This is not recommended because it
allows all new devices to be immediately approved to be managed by the core server.
Warn me when the number of unapproved certificates reaches [number]: When the number of unapproved
certificates reaches the number set in this field, a warning will appear, in the Console, telling the Administrator
there are certificates to approve.
Security Settings window

To see a graph showing all Client certificate-based security, open the Management Suite Console and click
Configure > Security. This will open the Security settings window.
 Security model page: Shows the graph of certificate-based authentication success rate.
o Select security model: Shows whether “Client certificate-based security” has been enabled.

o Approve client certificates: Provides a hot-link to the Client Access tool. (See Client Access section
for more detail.)
o Save authentication and decryption results: has the following two options:
 Save in inventory for each computer: Selects whether to include Client certificate-based security
information in the inventory for each computer. If selected, the inventory will populate in the Client
certificate-based security section in the LANDESK Management section of the device’s inventory.
 Save history in Security and Patch information: Selects whether to update Authentication status in
Client certificate-based security information when vulscan.exe is run on managed devices. This means
when vulscan.exe runs the Authentication required, Authentication succeeded, Certificate validation result,
Certificate validation result code, and Last authentication attempt, fields will be updated.
 Key manager page: Has the following options:
o Key management: Lists the current encryption key and the date the key was created.
o Generate key: Button which if selected generates a new encryption key. If you select this key the
following warning will appear:

o Approve client certificates: Provides a hot-link to the Client Access tool. (See Client Access section
for more detail.)
There is a hands-on exercise for discovering how the Client-side Certificates work.
Enhanced Macintosh™ Support

Management Suite supports Macintosh devices including enhanced manageability and the following:
 Security threat content enhancements for Macintosh include:
o Apple’s Gatekeeper feature
o Detection for Apple’s Filevault
o Require password for sleep and screensaver
o Logout Timer
 Antivirus support for Macintosh
o Client User-Interface now shows scheduled scans, tasks, and update information
o Full antivirus support for Macintosh (Kaspersky 8 for Macintosh)
o Pilot definitions for Macintosh
o Full and Quick scan abilities added to Mac scheduler
o Spyware and Adware option
o Auto-dialers option
o Install of AV can be part of agent install or a self-contained install
 Universal remote control viewer: Support for HTML 5 which adds ability to Remote Control from a
MAC via an HTML 5 compatible browser
 Agent Behaviors enhancements include:
o CPU Utilization settings while scanning inventory
o Vulnerability Scanning supporting:
 Immediate Patch install by group
 Supported scanning for
- Vulnerabilities
- Security Threats
- Blocked Applications
- Custom Definitions
- Autofix
o Repair Options including:

 Deferral messages before repairing, installing or uninstalling a patch
 Defer to locked machine or log off
 If no end user response there can be a wait or timeout
 Start repair even in full-screen
o Reboot Options including:
 Reboot only if needed
 Always reboot
 Reboot with a message
 Agent architecture including
o 64-bit architecture support
o Improved job status outputs
o Enhanced memory allocation
o Optional software policy improvements
o Software License Monitoring statistic enhancements
o Multicast cache only delivery method improvements
o Broker configuration automation during agent install
o Improvements on a manual retrieval of a CSA certificate
o CSA communication enhancements
 Improved integration with the Cloud Services Appliance
Virtual Desktop Interface Support

Virtual Desktops have been around for years. There are two types of Virtual Desktops, including persistent (i.e.
VMware™, and the Microsoft equivalent) and non-persistent. Management Suite 2016 supports persistent and
non-persistent Virtual Desktops.
An issue that non-persistent Virtual Desktops introduce is registry changes being lost when a user terminates
his or her session. When a new session is initialized, all previous registry data is not there, so the software
usage information, which Management Suite stores in the registry, is lost. Management Suite provides the
ability to optionally save registry modifications to a UNC share. When this is enabled, Softmon.exe writes
software usage data to the share, which the Inventory scanner (LDISCN32.EXE) can then report. With this
setting placed on non-persistent Virtual Desktops, software usage is reported. The Agent setting to enable the
Software Monitoring as well as where to store the Softmon information for Virtual Desktops is in Inventory
settings.

Once the Agent setting is created, it can be selected in the Agent configuration.

Legacy Agent Support: Deploying agents to Windows
XP/98/95/NT devices
Management Suite no longer ships with agents that support Windows XP, Windows 98, Windows 95, or
Windows NT devices. You can contact Ivanti Customer Support if you need the legacy agent that works with
these devices.
For more information on Agent Configuration, see, “LANDESK® Management Suite agent deployment
documentation” at: http://community.ivanti.com/support/docs/DOC-29574.
Agent configuration in mixed-language environments

When creating agent configurations in mixed-language environments, make sure the agent configuration name
uses only ASCII characters (English character set). An English core server is compatible with all supported
languages. However, if the agent configuration name uses non-ASCII characters, such as Japanese, Chinese,
or Russian, the agent configuration must be created on a core/console of that same language and will only
work on devices using the same language. For example, an agent configuration that includes Japanese
characters must be created on a Japanese core, and must be deployed to a Japanese client.
Creating a Managed Device

There are three (3) steps to take a device from unmanaged to managed:
4. Discover devices in the enterprise to be managed

5. Deploy the Management Suite Agent
6. Receive and process an inventory scan from the managed device
Scans received from a managed device are added to a Core Database, created during the Management Suite
installation, which in turn makes the device appear in the Network view on the Management Console. (See the
Consoles section.) When the device has an installed Agent, and appears in the Console, it is manageable
through the Console, so the Console User can perform various administrative management tasks on the
managed device.
Discovery
Discovery is the process of finding Unmanaged Devices (PC’s, printers, servers, switches, routers, or any
other device with an IP address, whether wired or wireless) on the network. The Discovery process looks for
devices referred to as Unmanaged Devices. Once identified, certain devices can have a Management Suite
Agent deployed to them, making them manageable from the Console from that point on.
Discovery can use two methods to find Unmanaged Devices, namely, Unmanaged Device Discovery (UDD),
and eXtended Device Discovery (XDD).
Unmanaged Device Discovery

The Unmanaged Device Discovery (UDD) method sends ping packet requests (ICMP protocol) on a
predefined subnet range, and listens for ICMP Replies. The information obtained from ICMP Reply packets is
used to compare with database entries to see if the responding machines are already present in the database.
The MAC address and the NetBIOS Name are in the response packets. Management Suite searches for those
entries in the database to ascertain whether the device is in the database.

If the corresponding MAC Address or NetBIOS Name, discovered in the network scan, is not present in the
database, the device will be added to the UDD tool.
UDD lists the Operation System, if known, on devices it discovers. If the device was discovered via NT Domain
discovery, the Operating System is listed in the Active Directory table, so UDD uses what is in the table to
populate the UDD column. For all other UDD discovery, Management Suite uses NMAP Operating System
Fingerprinting to discover the operating system on a Device. This technology sends malformed packets, which
each operating system responds to in different ways. Through the responses, the Operating System is often
discernable.
If you don't designate a subnet address range on a TCP/IP search, discovery is performed only on the network
segment where the console initiating the discovery resides. For example, if you've installed four Consoles on
four different PC workstations, each residing on a different network segment, you would have to initiate four
scans, one from each of the four Consoles.
On network segments where there are no PC workstations with Consoles installed, you must use a subnet
address range to scan that network segment.
To Launch a UDD Scan:
1. On the Management Suite Console click Tools > Configuration > Unmanaged Device Discovery.
2. On the Unmanaged Device Discovery tool click Scan Network (first icon on left on toolbar).
3. Enter the IP address range to scan in the Starting IP, Ending IP, and Subnet mask fields.
4. Click the More button if you desire to set additional scan options, then click Close.
a. Standard network scan
b. LANDESK Common Base Agent
c. NT or LDAP Domain discovery
d. LDAP
e. IPMI-enabled devices
f. Intel vPro-AMT devices
g. Virtual hosts
5. Click Add.
6. Click Scan now, or Schedule task, to scan immediately or schedule the scan for later.

If you click the [More] button, you will see this window:
 Discover devices using a standard network scan: Searches for computers by doing an NMAP ping
sweep. This is the most thorough search, but also the slowest. You can limit the search to certain IP and
subnet ranges. By default thi,s option uses NetBIOS to try and gather information about the device.
 IP OS Fingerprinting: Uses NMAP to try to discover what OS the device has.
 Use SNMP: UDD uses Simple Network Management Protocol (SNMP) to discover devices. Click Configure
to enter information about SNMP on your network.
 Discover devices with LANDESK PDS2 installed: Searches for the standard Management Suite Agent,
formerly called Ping Discovery Service 2 (PDS2) on computers. This option discovers computers that have
Management Suite products installed.
 Discover devices using NT domain: Searches for devices in a domain you specify.

 Discover devices using LDAP: Searches for devices in a specified Light-weight Directory Access
Protocol (LDAP) directory.
 Discover Virtual Host: Looks for servers running the VMware ESX Server.
UDD Rights
In order to perform UDD a Console User needs to have Unmanaged Device Discovery right assigned to them
through Role-Based Administration.
The View right grants the Console User the right to see and access the UDD tool. The Edit right grants the
ability to create UDD scanner configurations. The Deploy right grants the ability to schedule and run different
UDD scans.
UDD Limits
UDD (as helpful as it is) is dependent upon receiving reply packets to ping request packets. That presents at
least three limits: First, devices must be powered on. Second, devices must be connected to the network.
Third, devices must not be behind a firewall (whether on the device or network). With these limitations, a more
complete and thorough discovery method can be implemented.
eXtended Device Discovery

Extended device discovery (XDD) can help you find devices that UDD scans do not discover. XDD uses a
managed device elected to be a listener on its subnet. XDD enabled managed devices listen for Address
Resolution Protocol (ARP) broadcasts and maintain a cache (both in memory and in a file on the local drive) of
devices that make ARP requests. Networked devices use ARP to obtain a Dynamic Host Configuration
Protocol (DHCP) assigned address to join a network. Even heavily firewalled devices rely on ARP. Because of
this, XDD discovers devices that UDD scans do not discover.
Self-Electing Subnet Services

In Management Suite 2016.3, four services can be configured to use Self-Electing Subnet Services including
Extended device discovery (ARP), Extended device discovery (WAP), PXE Service, and Agentless scanner
service. These services elect a device to perform the required services for the subnet.
There are three benefits to using Self-Electing Subnet Services:

1. There is no longer a need for a separate Agent Setting or Agent Configuration to set devices to perform
required subnet services.

2. There is an automatic fail-over. If the elected device disconnects, a new device is elected and steps in to
act in the role to provide the service.
3. There is no duplication of services. Only one device on the subnet provides the service.
Client Self-Election Process

In order to have one (and only one) device performing services on each subnet, Management Suite uses a
unique and ingenious process called the Client Self-Election Process (CSEP). In CSEP, one device on each
subnet performs the role as the service provider. If that managed device is turned off or disconnects from the
network, another device dynamically steps in to provide the service. With this technology, each subnet always
has a service provider so no services are missed.
The CSEP implementation can eliminate the need to have multiple agent configurations for devices on
subnets. The self-election process makes it possible for each device to have the same configuration, and be
able to be a service provider, if elected.
Client Self-Election Process Architecture
1. In the Self-Electing Subnet services tool, the Console Administrator selects which services to enable, by
subnet.
2. The settings are set on the Core Server in the Client Self-Electing Subnet Tables. These call for the
election process by subnet.
3. Managed Clients with the Agent Setting to be elected run the services, offering one or more services if
elected.
Listener Technology and Actions

The managed device which enables services has the following technology:

 SelfElectController.exe (Process) – This contains the logic of the Self-Electing Subnet Services feature
o It is started and monitored to remain running by the Multicast service
o It creates an election score for each enabled service
o It enables elected Windows services when performing the role and disables them when not performing
the role
o It applies settings configured per subnet from the Core Server
o It reports service status back to the core for each election won
o SelfElect.dll knows how to communicate with the multicast service to perform self-election tasks
 TmcSvc.exe (Service) – This service assures that SelfElectController.exe is running and if it stops, for
some reason, it starts it again. (It checks every 10 seconds. It uses a locked file to determine if it is
running.)
Self-Electing Subnet Services Offered

 Extended device discovery ARP and WAP – The device on the subnet which becomes the XDD listener
loads the LANDesk(R) Extended device discovery service (XDDClient.exe), listens for and reports
devices on the subnet announcing themselves using Address Resolution Protocol (ARP) as well as the
devices announcing themselves using Wireless Access Protocol (WAP).
 PXE service – The device on the subnet which becomes the PXE (Pre-eXecution Environment)
Representative runs the LANDesk(R) PXE Service (pxesvc.exe) and the LANDesk(R) PXE MTFTP
Service (pxemtftp.exe) to provide PXE services for the subnet.
 Agentless scanner service – The device on the subnet which becomes the Agentless scanner service
representative loads the Management Suite Agentless Manager service (AGLSManager.exe) and scans
devices capable of running the scanner, sending the information to the LANDesk Inventory Server
service (LDInv32.exe), running on the Core Server, which populates inventory scans into the Management
Suite Database.
Steps to Enable Self-Electing Subnet Services

1. Configure, in the self-electing subnet services tool, which services to enable by subnet.
2. Create the Client connectivity settings for Self-Electing Subnet Services.
3. Deploy Client connectivity settings to Client devices.
4. Enable or disable any subnet services as desired.
Configure Self-elected Subnet Services

You can use the Self-electing subnet services tool to configure which services you want to enable and on
which subnets you want the services enabled.
Desired state of new networks

On the tool bar of the Self-electing subnet services tool, is a Set default state of new networks icon. Services
can be enabled or disabled for the following services:
 Extended device discovery (ARP)
 Extended device discovery (WAP)
 PXE service
 Agentless scanner service

The Management Suite Administrator can set the desired state of new networks to Enable or Disable each
service. As new networks appear in the list, the networks set to be enabled will use the election process to
select a managed device on the new network to run enabled services.
Regardless of how the desired state of new networks is set, the Administrator can right-click on any network
listed and either enable or disable each network as desired, overriding the default setting.
Create the Client Connectivity Settings

The second step to enable self-electing subnet services is to configure the Client connectivity agent setting
so managed devices are included in the election process for enabled services for the subnet. To do this, create
or edit a new agent setting.
Steps to create or edit a new client connection agent setting

1. In the Console click Tools (or Toolbox) > Configuration > Agent settings.
2. Click to create a new client connectivity agent setting (or edit an existing agent setting).
3. Select the Self-electing subnet services page and click to select the Enable self-electing subnet
services checkbox.
4. Set the desired interval in the Report election status frequency field. (This sets how often the devices
who are elected as “listeners” report that they are still actively listening. If the selected interval passes the

listener reporting, an election will select another device to take-over the listening role.)
5. Select the Extended device discovery page and set all parameters for the ARP and WAP listener
settings.
6. Select the PXE service page, and select whether to enable PXE service.
7. Select the Agentless scanner service page, and select whether to enable agentless scanner service, and
click the [Save] button. (The agent setting is saved with the selected settings.)
Parameters for Extended device discovery
 Use address resolution protocol (ARP): This checkbox selects whether to discover ARP announced
devices
o Duration ARP entry stats cached (in seconds): The length of time to keep discovered devices in the
cache (default 86400 or 1 day)
o Maximum delay before pinging an unknown device for the Management Suite Agent (in
seconds): (default 3600 or 1 hour)
o Frequency the cached ARP table is refreshed (in seconds): How often discovered devices are
reported to the Core Server (default 300 seconds or 5 minutes)

o Logging Level: The level of logging to select (IF the Force logging level checkbox is selected. Levels
include):
 1 – Errors only
 2 – Errors and Warnings
 3 – Debug
o Give desktops preference over laptops: This checkbox selects whether to weight the election
process to give desktops (as opposed to laptops) a higher probability of being selected to be the
listener.
 Use wireless access point discovery (WAP): This checkbox selects whether to discover Wireless access
point (WAP) devices.
o Frequency of WAP scan (in seconds): How often listeners scan to discovery WAP devices
o Logging Level: The level of logging to select (IF the Force logging level checkbox is selected. Levels
include):
 1 – Errors only
 2 – Errors and Warnings
 3 - Debug
Process for XDD Discovered Devices

If Management Suite does not find a corresponding MAC address or NetBIOS Name in the database, the Core
Server will act upon these added devices by waiting a random amount of time (between 15 minutes and 1
hour) to send a ping request to Agents that would exist on a managed device. The ping request packets from
the Core Server are TCP port 9595 to the Standard Management Suite Agent, TCP port 9535 to the
LANDESK Remote Control service, and TCP port 4343 to HTML5 Remote Control.
 Standard Management Suite Agent: Enables the Ping Discovery Service (PDS). If the standard
Management Suite Agent is installed on a device, you can schedule software distributions and device
setup configurations.
 Remote control: Lets you remotely access and control a device.
Any device that is not in the database, and does not send a response packet to the ping requests will be added
to the UDD list.
There is a column in the UDD list titled “ARP Discovered”. Items found via a UDD scan populate the ARP
Discovered field with “false”, while XDD discovered devices populate the field with “true”.
XDD can be set to listen to Wireless Access Point (WAP) traffic as well. If enabled, the listener will report
wireless routers to the Core, and these routers will appear in the UDD list.

Parameters for PXE service
Select whether or not you want PXE service to run on a managed device on the subnet.
Parameters for Agentless scanner service
Select whether or not you want the agentless scanner service run on a managed device on the subnet.
Deploy a Client Connectivity Agent Setting to a Managed Device

The third step to enable self-electing subnet services is to deploy the Client Connectivity agent setting (created
in the previous step) to a managed device. Remember the overall goal is to have all, or at least most, devices
on a subnet configured to be able to be elected as the listener, knowing that only one device per subnet will act
as the listener, and that if that device is turned off or leaves the subnet, another device will take-over self-
electing services roles.
Simply deploy an Agent Configuration which includes the desired Client Connectivity setting to devices not yet
managed in the Management Suite 2016 environment, or create a Change settings task to deploy the desired
agent setting to devices already managed in the Management Suite 2016 environment.

Enable or disable subnet services as desired
In the Self-electing subnet services tool, when you can click to select any of the services offered, the view will
show each subnet in the database, the desired state (whether the service is enabled or disabled for the
subnet), and if the subnet is enabled, the device elected to perform the subnet service. To override the setting,
simply right-click on the subnet network ID, and click to select to enable or disable the service for that subnet.
Self-Election Process
The self-election process designates one client per subnet to act as listener. If the listener is turned off or
leaves the network, another listener is elected to take-over the listener role.
Here are some rules about the self-election process:

 The selection to give desktops preference over laptops helps subnets to change listeners less often.
 In case a laptop device was designated as the listener, before it leaves a subnet, provision has been made
to not add devices the listener may hear from subnets external to the company, should the listener resume
its role on an external subnet.
 Managed devices on multiple subnets are given a lower priority to become a listener.
 If a device does not have an active wireless interface, it will not become a listener for XDD_WAP.
Self-Election Database Architecture

In order to manage the election and the process the following two tables and one view have been added to the
database:
 CSEP_Elections: Table containing a list of the clients that are elected and the current status.
 CSEP_Subnets: Table containing the desired state for a given subnet and service.
 CSEP_Elections_V: View which combines the two tables listed above.
The LDApi web service combines the CSEP_Elections_V with the Network ID’s from the bound adapter table
to produce a list of available subnets. This is what displays in the UI in the Console.
Potential orphaned records: Can happen when a client takes the election from a multi-homed machine but only
for one subnet. Those records will be removed during the Management Suite inventory maintenance.
There is an exercise for setting up Self-Electing Subnet Services.
The Agent Settings Tool

The Agent Settings tool provides ability to manage (create, modify, or schedule) settings for Management
Suite components. This facilitates scheduling deployment tasks to apply agent settings without have to
redeploying the entire agent to managed devices.
The Agent Setting tool can be launched from both the Configuration and Security and Compliance menus in
Tools and the Toolbox.
 Adaptive Settings:
In some environments, there may be a desire to lock-down a device or set it into a more protective mode
when the device is not located in the work-place. Adaptive Settings solves this business use-case.
An adaptive setting is basically a list of one or more rules ordered by priority. Using an adaptive settings
agent configuration, you can select multiple rules from a list of available rules.

The agent on the managed device will check the triggers for each rule in the selected rules list, starting at
the top. The first rule the agent encounters with a matching trigger will be applied and rule processing
stops. Only one rule can be active at a time. If no rules are triggered, the default settings specified in the
agent configuration page will be applied. (Note: If you apply an adaptive setting, it will cause .NET to be
installed on the device.)
There are two adaptive setting trigger types.

o Geofence (requires Windows 8 and a device with a Global Positioning System)
For geofencing, the target radius circle defaults to 10 meters. Increase the Radius if you want to
include a corporate campus, city, and so on. The geofencing minimum device accuracy determines
how accurate the GPS reading must be for the trigger to activate. If the GPS-reported accuracy
exceeds the value you specify, the trigger will not activate. In an adaptive setting you can set the
Check GPS location every interval. The default is two minutes. Frequent checks will reduce device
battery life.
o IP address range (works with any Windows device)

The IP address range Verify core existence on the network option can help prevent network
spoofing by making sure the Core Server is visible to the device. (Do not use this option with the IP
address ranges that will not have access to the Core Server.)
There are various settings which can be included in an adaptive settings rule, including:
Agent health, Client connectivity, Custom variables, Distribution and patch, Endpoint Security,
Inventory Settings, Ivanti Antivirus, Other security settings, Portal Manager, Remote Control, and
Remote control.
Adaptive settings rules can have one-time actions that execute when the rule activates. You can choose
from the following one time actions:
o Apply HP’s recommended locked-down security BIOS settings: This only works on HP devices.
You will need to provide the BIOS password.
o Lock Windows session: Locks the session so the user has to log back in. The can help prevent
unauthorized access when the device leaves a secure area.
o Run security scan: Runs the security scan that you select.
 Agent Health:
Settings here select whether to heal or replace the Management Suite Agent if the agent has been
removed, or if the agent settings have been altered.
o General: Sets the name of the Agent health setting, and Global behavior overrides for Autofix, and
Reboot. The Download Updates tool brings the source files for implementation.
o Components: Set which Agent Components to check for having possibly been removed or altered.
o Enforcement: Set how often to check for component having possibly been removed or altered.
o Settings: Set the desired Agent Setting to place on Agent Components which have been removed or
altered.
 Client connectivity:
Here you configure connectivity for the Core Server, Cloud Services Appliance, Download settings,
Preferred server, Self-electing subnet services, Extended device discovery, and Local scheduler.

o General: Set the Name for the Client Connectivity setting, and whether the setting is the default.
o Core Information: Settings for Core information include:
 Core certificates the client will trust: Select which of the public certificates (found in the
LDLogon share of the Core Server) to distribute to managed devices.
 Core address: Type the name of the core server and use the [Test] button to see if the name
successfully resolves.
 Path: Select a path if you do not want to use the Active Directory location.

o Cloud Services Appliance: Configuration settings her for connectivity with the Cloud Services
Appliance (CSA) including: Which CSAs to use, CSA failover policy, and how to connect to Core
Server when utilizing the CSA.
 Enable Cloud Services Appliance communication: Selects whether to use a Cloud Services
Appliance. All other selections on this page are then set as active and able to be utilized.
 Available CSAs to be used: Select which Cloud Service Appliance(s) to be set as active for this
Core Server.
 CSA failover policy: Select whether to User ordered list as shown in the selected items field, or
whether to Use a random order for failover.
 CSA connection mode: To select on the possible three options:
- Dynamically determine connection route: This selection is for devices which are
sometimes on the same network as the Core Server, and other times not.
- Connect directly to the Management Suite core: This selection is for devices which are
generally always on the same network as the Core Server.
- Connect using the Cloud Services Appliance: This selection is for devices which are
generally never on the same network as the Core Server.
o Download: Here you configure whether to block peer downloads (in Software Distribution,
Provisioning, etc.) over adapters you specify

 Block peer to peer downloading over wireless network adapter: Selecting this checkbox
blocks peer downloading when a device is connected to a network via a wireless network adapter.
 Block peer to peer downloading by network adapter description: Selecting this checkbox
blocks peer downloading when a device is connected to a network if the network adapter
description includes items entered into a configurable, case sensitive, list.
 Number of days files stay in cache: Sets how long managed devices will store files downloaded
to the SDMCache directory to offer to other peers.
 Modify client cache location: Allows selecting the location the client will use to cache files used
by Management Suite tools.
o Preferred Server: Configure the following settings concerning the Preferred Server:
 Update preferred server list from core every: To set how many Days and Hours to update the
preferred server list. This sets the maximum amount of time before a managed device will delete
the preferred server list to download and set again. (This setting populates to the Local Scheduler
the Management Suite Agent uses on the managed devices.) The preferred server list will also be
deleted if the IP address changes. (The default is once per day.)

 When downloading files: From the Preferred Server to download software in software
distribution, Patch remediations in patch management, or Images in OS Provisioning, how to work
downloading the file.
- Number of preferred servers to attempt before falling back to source: The default is
three servers.
- Number of files not found on preferred server before the server is moved to the end of
the preferred server priority list: The default is three.
o Self-electing subnet services: Select whether to enable the self-electing subnet services. A use case
for this option would be to disable this option for devices that are seldom connected to the corporate
network, and enable this option for devices that are usually connected to the corporate network. For
more information about self-electing subnet services, please reference “LANDESK Self Organizing
Multicast” on the Ivanti Community Website at: https://community.ivanti.com/support/docs/DOC-34266.
o Extended device discovery: Set whether to enable the listening service for eXtended Device
Discovery (XDD) and set its parameters. The suggested use is to have one device per subnet for each
subnet where XDD discovery is desired. (The device should usually be connected to the subnet and
turned on.)
o Use address resolution protocol (ARP): Selects whether to enable XDD discovery.
- Duration ARP entry stats cached (in seconds): Sets how long the listener will keep
discovered devices in its cache. The default is one (1) day.
- Maximum delay before pinging an unknown device for the Management Suite Agent (in
seconds): Sets the maximum time the Core Server will wait to send a ping request to the
Standard Management Suite Agent of the device if it is not found in the Management Suite
database.
- Frequency the cached ARP table is refreshed (in seconds): Sets the frequency the
listener will report newly discovered devices on that subnet to the Core Server. The default is
five (5) minutes. If no new devices are discovered during the time setting, no traffic is sent to
the Core Server.
- Logging Level: Sets the level (1 – Errors only, 2 – Errors and Warnings, 3 – Debug) of
logging for the XDD tool on the listener.
- Force logging level: Sets whether to enable logging.
- Give desktops preference over laptops: Selects whether to have desktops on a subnet
chosen over laptops for being an XDD listener, if multiple listeners exist on a chosen subnet.
o Use wireless access point discovery (WAP): Selects whether to enable wireless access point
discovery.
- Frequency of WAP scan in seconds: Selects the frequency the listener will scan for (and
report to the Core Server) wireless access points.
- Logging Level: Sets the level (1 – Errors only, 2 – Errors and Warnings, 3 – Debug) of
logging for the XDD tool on the listener.
- Force logging level: Sets whether to enable logging.

o Local scheduler: Sets the following configurations for the local scheduler:
 Frequency at which the agent polls the local registry for tasks: Sets two configuration
settings. Namely:
- General frequency: Sets how often the Local Scheduler (placed when Management Suite
Agent is deployed to the Managed Device) will look to see if it is time to launch a task. The
default is 10 seconds. This is a local check and does NOT produce network traffic.
- Bandwidth detection frequency: Sets how often to check the bandwidth being used to
download software, patch remediations, or images. This is to vary the download speed based
on available bandwidth, so as to not consume so much that other bandwidth consuming tasks
are affected too much.
 Bandwidth detection method: Sets the protocol to use to check for bandwidth usage.
- Internet Control Message Protocol (ICMP) can sense slow (Modem), medium (WAN), and fast
(LAN) speeds. (This is why it is the default selection.)
- Ping Discovery Service (PDS) can only sense slow and fast speeds.
 Bandwidth detection LAN threshold: Sets the threshold between medium and fast speed (for
the ICMP setting).
 Compliance:
Settings here set the Compliance settings within the Scan and Repair settings which Vulscan.exe will use
when scanning the Compliance group.

 Custom variables to override:
Items selected here exclude custom variables from being applied to managed devices. These settings
apply to Patch and Compliance.
 Distribution and Patch:

Settings here configure the way Distribution and Patch will download software distribution packages and
patch remediations. (For more information, see the Distribution and Patch settings section in the Patch
Management chapter.)
 HP:
Opens ability for three (3) different settings on Hewlett Packard managed devices.
o HP BIOS settings: Set the name, and perform the steps to set the HP BIOS feature.
o HP Remote Secure Erase: HP Remote Secure Erase (RSE) lets you remotely and securely erase
stored data on HP ElitePads. This function erases and overwrites all data on the device. This prevents
recovery utilities from “undeleting” data.

 Reprovision the device with the selected package: Lets you select which HP Remote Secure
Erase provisioning package to place on the HP device, erasing all that is currently on the hard
drive.
 Remove the package and reset the device to factory defaults: Resets the HP device to factory
defaults, and erases all that is currently on the hard drive.
 HP Remote Secure Erase Package Manager: Lets you create, import, or export an HP Remote
Secure Erase provisioning package.
o HP software policies: Here you set HP Power Assistant settings that can be deployed to HP devices.
Set the setting name and options to use for the HP software policies feature. This is similar to the
Power Management feature available in Management Suite 2016 except this is for HP managed
devices only.
 Inventory Settings:
Here you configure settings for the Inventory scanner LDINV32.exe.
o General settings: The page offers the following settings:
 Name: Set the name of the inventory setting.

 Enable scheduled task history maintenance: Here you select the checkbox if you want to keep
a scheduled task history in the client database. If enabled, set the number of days to keep the
scheduled task history.
 Run inventory scanner automatically after software package installation: Here you select the
checkbox if you want to update inventory data after software packages are installed, rather than
waiting for the next scan interval. You can configure a set number of minutes to delay the scan
(after the software has been installed) as well as add an additional random delay to stagger scans
from other devices.
 Set as default: Here you select if this inventory setting will be the default to be placed when new
agents are deployed.
o Location reporting: Here you select whether to enable location reporting, and if enabled, to configure
the collection intervals. This is what allows a Windows 8 device (with .NET 4.0) to use location
reporting. Location reporting requires the Let apps use my location to be enabled in the Windows 8
privacy settings.
The default data collection interval is four hours. If the device is marked lost (on the device’s inspector
dialog, Hewlett-Packard page, the When lost collection interval activates, providing more frequent
updates.
o Scanner settings: Here you select the following Inventory scanner settings:
 Send All Executed Files: Select whether or not to include all executed files (kept track in the
registry of the managed device) as a part of the inventory scan. (The default is to enable this
setting.)
 Send File Usage Data: Select whether or not to include file usage date (kept track in the registry
of the managed device) as a part of the inventory scan. (The default is to enable this setting.)
 Force Exhaustive File Scan (NOT Recommended): Select whether or not to include in the
inventory scan all file extensions. This results in lengthy scans and very large inventory files, and
is not recommended. (The default is to not enable this setting.)
 Auto-update LDAppl File: Select whether or not to have files run on managed devices added to
the Master Software List on the Core Server, if the files are not currently there. Items added
through enabling this feature can be seen in the Files > To be scanned section of the Manage
Software List tool. The use case of this feature is to find software which has been installed onto
managed devices but not yet executed, when just one device somewhere in the enterprise has
installed and run the software (and reports because of selecting the Send All Executed Files
feature mentioned above. (The default is to enable this setting.)
 Do Not Send Logon/Lock Event Dates: Select whether or not to report as a part of the inventory
scan the Operating System logon/lock event data. Some have privacy concerns and do not want
this data stored. (The default is to not enable this setting.)
 Post To Web Service: Select whether have managed devices send results of inventory scans to
the new web service running on the Core Server. Selecting this option sends the results of the
scan to the Web Service, whereas NOT selecting the option sends the results of the scan using
TCP port 5007 (the legacy method).
 Change History Storage (days): When the inventory scanner runs it creates a file containing
changes since the last scan stored as:
Program Files (x86)\LANDesk\LDClient\Data\ invdelta.dat.
The scanner sends this delta file as a scan to the Core Server. The inventory scanner also uses
the InvDelta.dat file to create a change log on each managed device. The changes log is saved in
XML format on each managed device in the LDClient\Data\changeslog.xml file. The Change

History Storage (days) sets how long history is stored in the changeslog.xml file on the managed
device. (The default setting is 90 days.)
 Software Scan Fequency (days): Sets how often to send software as a part of the Inventory
Scan. (The default is one day.) So that each day one scan sends hardware and software, while
each subsequent scan will be hardware only, unless software was installed and the Run inventory
scanner automatically after software package installation has been selected.
 Data File Extensions: Select whether to have other file extensions other than executable files
and those in the Inherited extensions field included as part of an inventory scan. Include the
period and the file extension to add other file types to the software scan. Separate each file
extension type with a space.
 Inherited extensions: Shows the global file extensions set in the Manage Software List tool in
Settings > DataFileExtensions.
o Software Usage Monitoring: Here you select software monitor settings, including:
 Use software monitor: Select whether or not to have the LANDESK(R) Software Monitoring
Service (Softmon.exe) run on the managed device to gather data on executable files run, and the
accompanying usage data, store it in the local registry, and include that information as a part of
the inventory scan.
 Record software usage statistics to a network location: Select whether to have Softmon.exe
store executable and usage information to a network share rather than to the registry. This is to
capture usage information on non-persistent Virtual Desktop Infrastructure (VDI) devices, since
starting VDI devices wipes any previous registry data.
 UNC path where software monitor data files will be stored: Set the UNC location
 Domain and user name: Enter the Domain\User with write rights to the UNC location.
 Password: Enter the password for the user in the Domain and user name field above.
 Confirm Password: Enter the password again, to confirm, for the user in the Domain and
user name field above.
o Schedule: Set in the Local Scheduler added as a part of the Management Suite Agent when to have
the inventory scan occur on each managed device with this inventory setting.
 When user logs in: Select whether to have the inventory scan occur each time a user logs in to
the managed device. The Max random delay field sets the maximum time to wait before sending
the scan, for randomization purposes. (The default does not select this setting.)
 When IP address changes: Select whether to have the Inventory Miniscan (Miniscan.exe) run
when the IP Address Filter is tripped. The miniscan will capture IP Address information to update
the Management Suite database. Miniscans go to the front of the line to process immediately so
the database is corrected shortly after the IP Address Filter has been tripped. (The default selects
this setting.)
 Use recurring schedule: Select whether to have the Inventory Scan regularly run on the
managed device. This is to periodically get a scan from every managed device in the enterprise, to
keep the Inventory Database accurate. (The default selects this setting of once each day, with up
to a 1 hour delay.)
 Mac configuration profile:

Set the Mac configuration profile settings. The Profile Manager on Apple’s OS X server lets you create Mac
configuration profiles. Each profile is an XML file with a .mobileconfig file extension that defines device
settings. For more information on Profile Manager, see

http://www.apple.com/support/osxserver/profilemanager/. Once configuration profile settings have been
created, use the Mac configuration profile setting to place the profile setting on the managed device as a
part of the Management Suite Agent.
o Name: Set the name of Mac configuration profile setting.
o Rules: Create profile settings with the Profile Manager tool on the Apple OS X server, and save them
as files with a .mobileconfig file suffix. Use the [Import] button to select the .mobileconfig files to
populate them into the Available configurations field. Use the arrows to move them to the Selected
configurations field to deploy as a part of the Management Suite Agent. Use the [Delete] button to
delete profile settings from the Available configurations field.
o Mode: Select the Append or Replace radio button to choose whether to replace all existing profile
settings on the managed device, or append to what the device already has set.
o Set as default: Select whether to have this setting as the default when deploying the Management
Suite Agent.
 Mobility – Mobile Compliance: Sets rules concerning mobility compliance and Email configuration.
o Compliance: Sets criteria for Jailbreak/Rooted, Geofence, and OS Version.
o Email Config: Sets The SMTP Server, Account, Port, and Password settings for compliance settings
that are violated to send emails.
 Mobility – Mobile Connectivity: Sets WiFi synchronization to mobility devices.

o General: Sets the name of the setting and whether or not it is the default setting.
o Certificate: Sets whether to enable certificate settings. If enabled: add the Public-Key Cryptography
Standard (PKCS)12 Certificate File, enter the password, and validate the cert. This setting gives ability
to add, edit, and remove, certificates.
o Wi-Fi: Configures the settings for synchronizing using WiFi.
 Setting name: Sets the WiFi setting name.
 Authentication SSID: Sets the Service Set Identifier.
- Auto Join: Selects whether or not to join the WiFi network automatically if within range.
- Hidden network: Selects whether or not the WiFi network is hidden or not.
 Authentication type: Set the authentication type. (Select from none, WPA, WPA2, WPA
Enterprise, or WPA2 Enterprise.
 Password: Set the password to log in to WiFi.
 Protocols Tab: Select the accepted protocols including: Accepted EAP types, EAP-Fast, and
Inner Identity TTLS.
 Authentication Tab: Set authentication parameters.
 Trust Tab: Set trusted parameters.
 Mobility – Exchange/Office 365: Sets synchronization settings mobility devices will use to send and
receive emails via the Exchange Server by locally using Office 365.
o Exchange/Office 365: Sets how mobile managed devices synchronize to Exchange™ Server using
Office 365™.
 Enable Exchange/Office 365 settings: Select whether or not to enable or not.
 Account name: Sets the account the mobile users will use.
 Server address: Sets the name of the Exchange Server.
 Allow user to move messages from this account: Sets whether or not to use this feature.

 Allow recent addresses to be synced using iCloud: Sets whether or not to use this feature.
 Only allow this account to send mail from the Mail app: Sets whether or not to use this
feature.
 Use SSL: Sets whether or not to synchronize using Secure Socket Layer (SSL).
 Past days of mail to sync: Sets how many days to include in the sync action. (The default is 3
Days.)
 Use email address from Active Directory to log in: Select whether to use the email address
listed in active directory for that user for the sync process.
 Hosted company domain: Enter the hosted domain name the web-hosted mail server is using for
inventory.
 Mobility – Security: Sets parameters for iOS mobility devices.

o Passcode: Sets whether to enable passcode settings including: minimum password quality, minimum
password length, whether to lock the screen after synchronization, and the maximum number of failed
password attempts before device wipe.
o iOS Restrictions: Set whether to enable iOS restrictions which can include the following settings:
Device functionality, Applications, Content and Ratings, Single-app mode (Kiosk), iCloud, and Security
and Privacy.
 Portal manager:
Create setting to deploy to managed devices as a Portal manager setting. On the managed device the
Portal Manager lists the available applications, documents, and links available to the managed device.
o General: This page lets you select the following:
 Name: Set the name of the Portal Manager setting.
 Allow resize: Select whether to allow the end-user to resize the Portal Manager on the managed
device.
 Allow close: Select whether to allow the end-user to close the Portal Manager on the managed
device.
 Launch maximized: Select whether to launch the Portal Manager on the managed device as a
maximized window.
 Set as default: Select whether to have this setting as the default when deploying the
Management Suite Agent.
 Default display option View: Select whether the Portal Manager will show available applications,
documents, and links, in List, Small icons, or Large icons form.
 Available types: Select whether to list Apps, Docs, and/or Links in the Portal Manager on the
managed devices.
o Applications: Select whether to show the LaunchPad, and/or Task History in to Portal Manager on
the managed devices.
o Branding: Select options here concerning how you want the Portal Manager to look on the managed
devices.
 Application title: Type the title as you want it to appear in the Portal Manager.
 Choose title color: Select the color you want the text in the title to appear in the Portal Manager.
 Taskbar icon: Select the icon you want in the taskbar in the Portal Manager.
 Corporate logo: Select the logo you want in the taskbar in the Portal Manager. (The optimum
size is 135 X 52 pixels.)

 Choose background image: Select the background image you want in the Portal Manager.
When all of the settings have been selected, use the [Preview branding] button to see what the
Portal Manager will look.
o Workspaces
 Allow single sign on: Selects whether to allow single sign on to open Workspaces, which will
pass the account used to log in to the managed device.
 Allow offline access: Selects whether to allow offline access.
 Start page: Sets whether to start on the Launchpad or Logon page.
 Power Management – Mac Power management settings: Sets parameters for Macintosh devices with
power management.
o General setting: Set the following options:
 Policy name: Set the name of the policy.
 Policy description: Set a description of the policy.
 Battery tab: Set when on battery power to: have the computer sleep, the display sleep, whether to
put hard disks to sleep when possible, slightly dim the display while on battery power, and whether
to enable the Power Nap setting (for solid state disks).
 Power Adapter tab: Set when on power adapter to: have the computer sleep, the display sleep,
whether to put hard disks to sleep when possible, whether to wake for network access, whether to
allow the power button to put the computer to sleep (for OS X pre 10.9), whether to start up
automatically after a power failure, and whether to enable the Power Nap setting (for solid state
disks).
o Schedule: Set whether to schedule Startup or wake, sleep, restart, or shut down.
 Power Management – Power management settings: Sets parameters for Windows devices with power
management.
o Power configuration: Set the following options:
 Policy name: Set the name of the policy.
 Policy description: Set a description of the policy.
 Power scheme settings: Add to a power scheme, which can be deployed, settings to: hibernate,
standby, turn on, turn off, and alert.
o Options: Set whether to: disable the screen saver, whether to enable local wakeup, set process-
sensitive triggers (to not have the device use power management settings if certain applications are
running), whether to enable usage monitor, whether to enforce ending a process before going into a
power management mode, how power buttons act (including: when the power button is pressed, when
the sleep button is pressed, and when the lid is closed), whether to enable CPU throttling (including: if
plugged in, or on battery).
 Reboot settings:
Here you set reboot settings for when deploying the Management Suite Agent, installing Software
Distribution Packages, and installing Patch Remediations.
o General: Set the following parameters in the General page:
 Name: Set the name of Reboot setting.
 When deciding whether a reboot is needed: Allows you to select one (1) of next three (3)
settings:

- Act as if reboot is ALWAYS needed: This option will force a reboot, regardless of whether
the Management Suite Agent or the Windows Operating System indicates whether a reboot is
needed.
- Detect whether reboot is needed: (This is the default setting) This option checks both the
Management Suite Agent and the Windows Operating System to see if either indicate
whether a reboot is needed. If either recommends a reboot, it will be initiated.
- Act as if reboot is NEVER needed: This setting will disable all other reboot settings,
regardless of whether the Management Suite Agent or the Windows Operating System
recommends one.
- Suppress Windows update reboot notifications: This setting will prevent the Windows
Update service from displaying reboot notifications in the task tray.
- Set As Default: Select whether to have this setting as the default when deploying the
o Prompt: Select and set the following settings regarding how reboot dialog will display to the end user
on the managed device.
 Prompt user before rebooting: Select whether or not to prompt the user before rebooting. Type
into the field which follows the text you want to appear in the window presented to the user when a
reboot needs to occur. The [Use default message] box sets the text in the window to say,
“LANDESK has detected that this computer should be rebooted.”
 Allow users to defer reboot (snooze) for: Sets the amount of time the end-user can defer the
reboot until the reboot will be forced. The user will be able to choose how many times to defer and
how long to wait within this time period. (The default is 7 days, but selections can be made for
Days, Hours, and Minutes.
 Show system tray icon when a reboot is required: Select whether to have the reboot icon
appear in the system tray. If the user defers the reboot for a time, but decides a reboot is
opportune sooner, the user can select the icon in the system tray and initiate the reboot sooner.
 Customize window caption: Select whether to have custom text appear in the title bar of the
reboot prompt. When selected, the text is the subsequent field will appear in the caption of the
reboot prompt.
 Preview: Click the [Preview] box to see how the reboot prompt will look to the end user.
o Automatic reboot: Lets you set various settings to trigger an automatic reboot.
 Automatically reboot if any of these options are selected: The reboot will occur if the
managed device meets any of the select option, whichever happens first.
 Logged out for: The managed device will reboot if the user has been logged out for the
specified amount of time.
 Locked or logged out for: The managed device will reboot if the machine has been locked
or logged out for the specified amount of time.
 No response to reboot prompt for: The managed device will reboot if the user does not
reboot before the specified time.
 Reboot deadline exceeds: The managed device will reboot if the user does not reboot
before the specified time.
 Limit automatic reboot in the specified time window: Select whether to add additional
time parameters for the automatic reboot. You can set the time of day and the days of the
week. Selecting this option specifies a maintenance window for a reboot.
o Do not disturb: Lets you set the following options:

 Do not reboot or prompt to reboot if specified processes are running: Select whether to
override a reboot, or prompt to reboot, if there are designated, key applications running on the
managed device.
 Add defaults: Clicking this box will add keynote.app, powerpnt.exe, PowerPoint.app, and
pptview.exe applications which are in full screen mode, to override a reboot or reboot prompt.
 Add: Allows adding applications in one of two filter modes. Either Any time process is running,
or Only when process is running full screen.
 Edit: Allows selecting an application already listed, and changing the filter mode.
 Delete: Allows deleting application listed for reboot override.
 Import: Opens the Import dialog box where you can select processes from the Do not disturb
lists in other settings, such as Distribution and patch.
 Remote control:
Set configuration settings to apply as a Remote Control setting on managed devices.
o General settings: On this page, you can set and select the following:
 Name: Type the desired name of the Remote Control setting.
 Allow HTML access: Select whether to install the HTML access remote control on the managed
devices.
 Allow legacy remote access: Select whether to install the legacy remote access remote control
on the managed devices.
 Allow: Select whether to allow the following:
- Remote control: Select whether to be able to view the screen and interact using keyboard
and mouse on the remote device.
- Draw: Select whether to be able to use the draw feature on the remote device. (This requires
remote control to be selected.)
- View only: View the screen but not have keyboard and mouse functionality on the remote
device. (This requires remote control to be selected.)
- Restart: Select whether to be able to remotely restart the remote device.
- Run programs on remote device: Select whether to be able to run programs (launch
applications) on the remote device.
- Run as administrator: Select whether to run programs launched during the remote session
as administrator.
- File transfer: Select whether to be able to transfer files to or from the remote device during
the remote session.
 Set as default: Select whether to have this setting as the default when deploying the
o Indicator settings: On this page, you can select the following remote control indicators:
 Floating desktop icon: Select whether to display an icon on the desktop of the managed device.
- Only visible during remote control: The display icon will appear on the background of the
remote desktop only during the remote control session, giving the end user visible
confirmation when someone is viewing them.
- Always visible: The display icon will appear on the background of the remote desktop when
the LANDESK Remote Control Service is running on the managed device. The end-user
will not know when someone is viewing them, or not.
 System tray icon: Select whether to display an icon in the system tray on the managed device.

- Only visible during remote control: The display icon will appear on the system tray of the
confirmation when someone is viewing them.
- Always visible: The display icon will appear on the system tray on remote desktop when the
LANDESK Remote Control Service is running on the managed device. The end-user will
not know when someone is viewing them, or not.
o Permission settings: Select the following permission settings for the Remote Control setting:
 Permission not needed, full access: Select this setting to NOT request permission of the end-
user to start a remote control session on the managed device.
 End user must grant permission and must be logged in: Select this setting to require the end-
user to grant permission to start a remote control session on the managed device. If the user is
logged out, a remote session cannot be initiated with the managed device.
 End user must grant permission, but only if they are logged in: Select this setting to require
the end-user to grant permission to start a remote control session on the managed device. If no
one is logged in, the remote session is allowed, but since the screen will be at a login prompt, the
person initiating the remote control session will have to know a password to gain access to the
device.
 End user must grant permission: Select this setting to send a request dialog to start a remote
control session on the managed device. A remote control session is not allowed unless permission
is granted.
 Display a custom message: Select whether to prompt the user on the managed device with a
custom message to ask permission to initiate Remote control, Chat, Remote execute, File
transfer, Restart, or All permissions. The custom message is typed in the subsequent field.
 Ask permission to use all features at one time: Select whether to ask once per remote session
for all features allowed during the remote control session. If unselected, request dialogs will be
sent to use each feature during each remote control session.
 Close permission message box after: Sets the number of seconds to display the request to
initiate a remote control session. If permission is not granted by the end user on the managed
device within the specified time frame, the request closes without permission being grated to
initiate the remote control session.
o Security settings: On this page, you can select the following remote control security settings:
 Local template (least secure): Select to grant ability to any person initiating a LANDESK remote
control viewer to initiate a remote control session. Any of the settings granted on the General
settings page will be able to be utilized during the remote control session. This setting does not
verify if the user is a member of a specific group, has the LANDESK remote control viewer from a
specific Core Server, or any other verification of security. Hence it is the least secure setting.
 Windows NT security / local template: Select to limit the person initiating a remote control
session to be a member of the Remote Control Operators group, which is installed on the
managed device when the remote control setting is placed on the managed device. Members of
the Remote control operator groups can view and interface using the keyboard and mouse
during the remote control session. Member of the View only group can only view the display
during the remote control session. Use the [Add] and [Remove] buttons to add members to the
two groups.
o Session settings: On this page, you can select the following remote control session settings:
 Lock the remote computer when session ends: Select to lock the managed device to a secure
mode once the remote control session ends.

 Terminate remote access if the user logs out or locks the machine: Select to automatically
end the remote control session if the end user logs out or locks the managed device.
 Allow the end user to terminate the session: Select to allow the end user on the managed
device to access end the Remote Control session. The end user can access the remote control
desktop icon or the remote control system tray icon to stop the active remote control session. If
this option is not selected, the end user of the managed device cannot stop and active session
through either icon.
 Close inactive session after: Sets the time period to automatically end the remote control
session of there is no keyboard or mouse activity. Set the time to 0 to disable this feature.
o Security:
Security opens access to create settings for Endpoint Security (for Application Control, Application
File Lists, Device Control, LANDESK Firewall), Ivanti Antivirus, Ivanti antivirus – Mac, Ivanti
Antivirus Legacy, Other security settings, and Windows Firewall. These will not be addressed in detail
here. To see more on these settings, please refer to the modules dealing with security.
Agent Configurations
Management Suite uses Agent Configurations that you create to deploy agents (and associated preferences
and configurations) to Managed Devices. Once Devices have Management Suite Agents on them, you can
easily update Agent Configurations.
Agent Configuration Tool

The Agent Configuration tool is used to create and update Agent Configurations for all devices. Different
configurations can be created for department or group specific needs. For example, configurations can be
created for the devices in the accounting department or for devices using a particular operating system.
Management Suite version 2016 provides nine Agent Configuration types, including:
 New Windows agent configuration – for Windows workstations
 New Windows Server agent configuration – for Windows servers
 New Windows Embedded Standard agent configuration – for embedded devices
 New Mac agent configuration
 New Linux agent configuration
 New HPUX agent configuration
 New Solaris agent configuration
 New HP ThinPro Linux agent configuration
 New AIX agent configuration
Management Suite supports various operating systems to provide vast cross-platform support. Each operating
system can have one default configuration. The default configuration cannot be deleted, but it can be edited.
(The default configurations have a green checkmark.) It is recommended that a configuration be created for
each different client requirement, while not creating more than are needed, as this makes support and
troubleshooting more complex and time-consuming.
Creating an Agent Configuration (or using the default configuration) involves considerable planning and testing.
It is best to deploy the correct configuration the first time, although the agent can be reconfigured and
redeployed again if necessary. With agent settings, you can deploy small pieces of an agent configuration
rather than deploying a complete agent again.

An organization may need to have multiple Agent Configurations. For example, a laptop system might need a
different configuration than a desktop system. In order to avoid deploying the wrong agent to the wrong
system, it is important to adopt a sensible naming convention for each Agent Configuration.
Agent Configuration Components

The Agent Configuration contains several components by default. Other components are optional and added
as custom components
 Security and Patch Scanner - The security and patch scanner agent is installed by default with the
standard Management Suite Agent. You can configure security scans to determine how and when the
security scanner runs on managed devices and whether to show progress and interactive options to the
end user. (The security scanner allows you to check for Ivanti updates on devices and core servers
even if you don't have an Ivanti Security Suite content subscription. With a Security Suite subscription,
you can take full advantage of the security scanner's capability to scan for and remediate known
vulnerabilities, spyware, unauthorized applications, and other potential security risks.)
 Inventory Scanner – The inventory scan is scheduled by default with the standard Management Suite
Agent. You can configure the frequency of inventory scans in the Agent Configuration.
The Ivanti Community has a variety of Agent Configuration and Deployment documents and videos. To access
them, go to the “Management Suite Agent Deployment Landing Page” located at:
The landing page offers:
 Videos
o Agent Installation Methods
o Agent Configuration
o Management Suite 9 Fundamentals Agent Configuration
o Agent Deployment via Login Script
o Agent Deployment via WSCFG32.
 Documents
o How to Create an Advance Agent
o Documentation for Agent Configuration and Deployment (Best Known Method for LANDESK 9)
o Troubleshooting Agent Installs
o Advance Agent Install process and troubleshooting tips
o Why can’t I install the Advance Agent over itself on a client
o UninstallWinClinet.exe may not run correctly on Windows 7 under UAC
o How to completely remove LANDESK from a remote console or client device
o Customizing the Management Suite Agent using the NTSTACFG.IN# file
o How to uninstall the Management Suite Agent on Windows Platforms
o How to uninstall the Management Suite Agent on Macintosh Platforms
Before deploying agents, be sure to reference “Best Known Methods Agent Config & Deploy.pdf on the Ivanti
User Community Web site at: http://community.ivanti.com/support/docs/DOC-7474.
Important
When creating Agent Configurations in mixed-language environments, make sure the Agent
Configuration name uses only ASCII characters (English character set). An English core server is
compatible with clients using all supported languages.

However, if the Agent Configuration name uses a non-ASCII characters, such as Japanese,
Chinese, or Russian, the Agent Configuration must be created on a core/console of that same
language and will only work on devices using the same language. (For example, an Agent
Configuration that includes Japanese characters must be created on a Japanese core, and must
be deployed to a Japanese client.)
Create an Agent Configuration

Use the Agent configuration tool to create and update Agent Configurations. Different Agent Configurations
can include or exclude Management Suite tools (such as Remote Control, Custom data forms, Power
Management, Real-time Inventory and Monitoring, etc.).
You can create different configurations for a group’s specific needs. For example, you could create
configurations ideal for servers, as opposed to workstations, (such as when Patch scanning occurs or reboots
after applying patches), or for hierarchical needs (such as if remote control requires permission or not).
To Create an Agent Configuration to push to devices, you have the following options:
 Default Agent Configuration: Modify one of the default Agent Configurations for each of the supported
operating systems. Default agents are used as a template for creating, for example, multiple Windows
OS Agents.
 Create a New Agent Configuration: Create a new Agent Configuration for your devices.
To create an agent configuration

1. In the console, click Tools > Configuration > Agent configuration.
2. In the Agent Configuration toolbar, click the New Agent Configuration icon.
3. Click to select one of the agent options from the drop-down list
 New Windows agent configuration
 New Windows Server agent configuration
 New Windows Embedded Standard agent configuration
 New Mac agent configuration
 New Linux agent configuration
 New HPUX agent configuration
 New Solaris agent configuration
 New HP ThinkPro Linux agent configuration
 New AIX agent configuration
4. Enter a Configuration name.
5. In the Agent configuration window, select the agents you want to deploy.
6. Use the tree to navigate the dialogs relating to the options you selected. Customize the options you
selected as necessary. Click Help for more information if you have questions about a page.
7. Click Save.
8. If you want the configuration to be the default (the configuration ldlogon\wscfg32.exe or
ldlogon\IPSETUP.BAT will install), from the configuration's shortcut menu, click Default configuration.
Creating a Windows Agent Configuration

To create a Windows Agent configuration, whether for servers or workstations, you have a variety of options
you can set in the agent. The Standard Management Suite Agent and the Software distribution components
will be installed as a part of every agent. Settings beyond that are optional.

 Start - The start page offers options to name the configuration, options of which agent components to
install, .NET installation options, inventory scan behavior, whether to show agent components in the start
menu, and the temporary install directory.

 Standard Management Suite Agent - The standard Management Suite Agent page offers options for
global settings (for when patch management runs), and agent install reboot settings (to set how a reboot
will be handled IF the agent install requires a reboot after the agent is installed).
 Client connectivity – The client connectivity page offers options to edit, configure, and select the desired
client connectivity agent setting.
 Inventory settings – The inventory settings page offers options to edit, configure, and select the desired
inventory agent setting.
 Alerting – The alerting page offers options to add or remove alert rulesets.
 Reboot settings – The reboot settings page offers options to edit, configure, and select, the desired reboot
settings. This setting will designate how to handle a reboot after the Install/uninstall of a software
distribution package or install/uninstall of a patch, IF they require a reboot.
 Custom data forms – The custom data forms page offers whether to manually or automatically launch the
update of custom forms, and when to display the forms to the end user. The forms sent with agent page is
used to assign the forms to send as a part of the agent configuration.
 Distribution and Patch – The distribution and patch page offers options to edit, configure, and select the
desired distribution and patch agent setting.
 Portal manager – The portal manager page offers options to edit, configure, and select the desired portal
manager agent setting. It also offers selection boxes for adding portal manager to:
o LANDESK Program Group
o Windows Desktop
o Windows Start menu
o Run Portal Manager when the user logs on
 Workspaces – The workspaces page offers a selection box for adding workspaces to the Management
Suite program group when the agent is installed.
 Security and compliance – The Security and compliance page gives access to Custom variables, Ivanti
Antivirus, Windows Firewall, Endpoint security, Agent watcher, and Other security pages with their
accompanying selections.

 Remote control – The remote control page offers options to configure and select the desired remote
control agent settings as well as selection boxes to
o use mirror driver (faster performance)
o use screen blanking driver
 Power management – The power management page offers options to edit, configure, and select the
power management agent settings. It also offers a selection box to apply power management settings to
this configuration.
 Adaptive settings – The adaptive settings page offers options to edit, configure, and select, the adaptive
setting agent settings. It also offers a selection box to apply adaptive settings to this configuration.
To Push an Agent Configuration to devices

To push an Agent to devices you have the following options:
 Manual Default Agent Deployment: Users with administrative rights can install the default Agent
Configuration manually by running WSCFG32.EXE or IPSETUP.BAT from the Core Server’s LDLogon
share.
 Set the Agent Installation as part of a Login Script: You can use an LDAP login script or Active
Directory Group Policy Object (GPO).
 Schedule the agent configuration: Push the Agent Configuration to discovered Unmanaged Devices or
Devices that already have the standard Management Suite Agent installed. An "advance agent
configuration" is usually the best choice. For more information, see the section, "Using the advance agent".
The Agent Settings tool provides a single location to manage (create or modify) configurations to various
components and services. This facilitates scheduling deployment tasks to apply newly created configurations,
as well as modified settings, without redeploying the entire agent to managed devices.
The Agent Setting tool can be launched from both the Configuration and Security and Compliance menus in
Tools and the Toolbox.
For more information on the agent settings tool, please see the Agent Settings Tool section.
Prior to creating and deploying a Management Suite Agent, a decision should be made as to whether
the Remote Control will use the Federal Information Processing Standard 140-2 mode.

or later.

 ProxyHost.exe on the remote device (which provides general Management Suite Agent communication).
SSL certificate set is created in the C:\Program Files (x86)\LANDesk\Shared Files\Keys directory. The old SSL
certificates are moved to the C:\Program Files (x86)\LANDesk\Shared Files\Keys\Backup\<Date and Time>
directory.
managed.

you want to manage.

mode?)
Ivanti Services window will appear stating: “The LANDESK® Management Gateway Service must be
restarted before your changes will take effect. Do you wish to restart it now?)
13. If this Configure Ivanti Services window appears, Click [Yes].
14. A Configure Ivanti Services window appears stating: “You must restart the services that use the database
before your changes will take effect.” Click [OK].
NOTE: If FIPS 140-2 is enabled on a Core Server, EACH Cloud Services Appliance for that Core Server must
be configured to use FIPS 140-2 mode.
Using the Advance Agent

The Advance Agent is the preferred method for deploying the agent in most environments. This agent has
been created to leverage Management Suite bandwidth-friendly technology during the agent deployment. It
can reduce the amount of network bandwidth used for Windows-based agent configuration. The Advance
agent uses a two stage deployment method. The Advance agent is an MSI file that is deployed in advance of
the full agent. The MSI installs and then initiates the bandwidth sensitive download and installation of the
Agent.
Here is an example of an advance agent created for the LDClass Agent:
The Advance Agent uses two files to install the Agent. The first file is a small .MSI package, which launches an
HTTPCopy utility to pull the Agent. When this file runs on a managed device, it downloads and runs the
Advance Agent service on the Device. The HTTPCopy utility uses bandwidth throttling, configured earlier, to
download the Management Suite Agent, (which in this case is the LDClass Windows Server Agent
Configuration application file). The size of the file varies depending on the Management Suite tools included in
the agent configuration. In the Advance Agent Configuration dialog, you can configure what bandwidth-friendly
distribution options the MSI will use for the full agent configuration download.

The Advance Agent works well for most devices, including laptops with intermittent or slow network
connections. However, it doesn't support PDAs and other handheld devices.
The advance agent works independently from the core server once it starts downloading the full agent
configuration. If a device disconnects from the network before the agent configuration finishes downloading,
the advance agent will automatically resume the download once the device is back on the network.
When you create an Advance Agent Configuration, it takes a few seconds for the console to create the full
agent configuration package. The console places the advance agent package (<configuration name>.msi) and
the newly-created full agent configuration package (<configuration name>.exe) in the core server's
LDLogon\AdvanceAgent folder. The file names are based on the agent configuration name.
Once you've created an Advance Agent Configuration package, you need to run the MSI portion on devices by
scheduling the Advance Agent Install or invoking the .MSI file via Group Policy Object (GPO).
Once you deploy the advance agent to devices, the advance agent starts downloading the associated agent
configuration. The agent runs silently on the managed device, without showing any dialogs or status updates.
The advance agent uses the bandwidth preferences you specified in the Advance agent configuration dialog,
such as Peer Download and dynamic bandwidth throttling.

Once the MSI installs and successfully configures agents on a device, it removes the full agent configuration
package and the LANDESK Advance Agent service. The MSI portion stays on the device, and if the same MSI
runs again it won't reinstall the agents.
To create an advance agent configuration

1. Create a Windows-based agent configuration (Tools > Configuration > Agent configuration).
2. From that configuration's shortcut menu, click Advance agent.
There are two configuration options:
a. Download the executable file from a location on the network, and
b. Peer download.
- If you select download the executable file from a location on the network, the Advance Agent files
will be created in a default location. If relocating the associated Agent Configuration package (the .exe
file), change the path for the Agent Configuration to match the new location.
- If you select Peer download, make sure that the advance agent .msi file and the full agent configuration
.exe package are in the software distribution cache (C:\Program Files\LANDesk\ LDClient\sdmcache
directory) of a device in the broadcast domain. If you select Peer download and don't do this before
deploying the advance agent configuration, the deployment will fail because no cache or peer in the
broadcast domain has the necessary files.
3. Click OK.
4. If necessary, copy the associated .exe file from the LDLogon\AdvanceAgent folder to your distribution
server. Make sure the path to the agent configuration executable matches the path you specified in the
Advance agent configuration dialog. You should leave the MSI package on the core server in the default
location. Otherwise, the package won't be visible for the advance agent push distribution task (below).
To set up an advance agent push distribution

1. In the Agent configuration window (Tools > Configuration > Agent configuration), click the Schedule a push
of an advance agent configuration button.
2. The Advance agent configurations dialog lists the agent configurations in the LDLogon\AdvanceAgent
folder. Click the configuration you want to distribute and click OK.
3. The Scheduled tasks window opens with the advance agent task you created selected. The task name is
"Advance agent <your configuration name>".

4. Add target devices to the task by dragging them from the Unmanaged Device Discovery, or the Network
view > All Devices, and dropping them on the task in the Scheduled tasks window.
5. From the task's shortcut menu, click Properties and schedule the task. You can see the MSI portion
distribution progress in the Scheduled tasks window. There are no status updates on the full agent
configuration once the MSI distribution completes.
Pulling the Management Suite Agent from the Core

Server
If there is a need to install or update a Management Suite Agent from a Device in the enterprise this can easily
be done. From the device where the agent is to be installed or updated, run:
\\<CoreServerName or IP Address>\ldlogon\wscfg32.exe
Running wscfg32.exe will install the default Agent Configuration. If there is a need to install or update a non-
default agent use the /c command line switch (/c[onfig]=Path to the installation script (ini) file). For a list of
command line options available for wscfg32.exe, see the document “WSCFG.EXE (agent installation utility) –
Command Line switches” on the community web site at: http://community.ivanti.com/support/docs/DOC-1102.
Scheduling Deployment of the Management Suite Agent

While the Best Known Method for deploying the Management Suite Agent is to use the Advance Agent, there
still may be times where you want to push an Agent Configuration to a Device. To Schedule an Agent
Deployment:
1. Open the Agent Deployment tool in the Console (Tools > Configuration > Agent Configuration).
2. Right-click on the Configuration you wish to deploy, and click Schedule agent deployment.
3. Drag devices from UDD, or from the inventory list, or device groups, queries, or LDAP, and drop them
onto the scheduled task.
4. Start the task.
Note: in order for the Agent to deploy to the managed device, the Scheduler must be configured to use an
Administrative account, as directed in the Getting Started wizard.
Create standalone Agent Configuration packages

If you want to install Agents from a CD, or portable USB drive, or a network share, you can create a self-
contained client (Agent) installation package.
To create a standalone agent configuration package
1. Click Tools > Configuration > Agent configuration.

2. Customize the configuration you want to use.
3. When you're done, from the configuration's shortcut menu, click Create self-contained agent installation
package.
4. Select the path where you want the package stored. Make sure the file name contains only ASCII
characters (a-z, A-Z, 0-9).
5. Wait for Management Suite to create the package. It may take a few minutes.
Now the .exe file can be copied to a CD, portable USB drive, or a network share.
NOTE: If a self-contained client installation package has been created, and after that, the Agent Configuration
is modified, the self-contained client installation package (<filename>.exe) must be deleted, recreated, and re-
copied to all destinations from which it is run.
Uninstalling Device Agents

To uninstall the Management Suite Agent from a Windows device, run UninstallWinClient.exe located in the
LDMain share. Only administrators have access to this share. This program uninstalls Management Suite
Agents on any device it runs on. You can move it to any folder you want or add it to a login script. It runs
silently (without displaying an interface).
Running this program won't remove a device from the Core Database. If you redeploy agents to a device that
ran this program, it will be stored in the database as a new device.
Update Agent settings on Managed Devices

If you want to update Agent settings on devices, such as requiring permission for remote control, you don't
have to redeploy the entire agent configuration. You can make the changes you want in the Agent settings tool.
Select Create a task to Change settings. You then select the setting(s) you wish to schedule. This opens the
Scheduled tasks window with your selection(s) where you can select devices to which you will deploy the
setting(s), and start the task.
Mobility Management
Management Suite 2016 includes ability to manage iOS™ and Android™ mobile devices. Each purchased
license to manage a non-mobile device in Management Suite includes two licenses to manage mobile devices.
Setup
The Mobility Device Manager (MDM) server was separate from the Core Server in previous versions of
Management Suite. In Management Suite 2016 the MDM is now on the Core Server. The Mobile Device
Management wizard helps you configure the core server as the MDM. To manage the mobile device in
Management Suite 2016, a Cloud Services Appliance (CSA) must be used. The mobile devices send inventory
and receive policy updates via communication to the CSA, which relays information and communication to the
Core Server.
Management Suite 2016 provides a wizard to set up the Core Server as the MDM. It walks you through:
 Setting up communication with the Cloud Services Appliance and Mobility.
 Configuring the Light-weight Directory Access Protocol (LDAP) server communication so users can enroll
with their domain credentials.
 Configuring Google Cloud Messaging (GCM) for communication with Android devices.
 Configuring Apple Push Notification Service (APNS) for communication with Apple iOS devices.

 Configuring iOS Profile Signing to set security options to cryptographically sign Apple iOS profiles before
sending them to devices.
For more information on setting up the MDM on the Core Server, see “Getting Started with Mobility LANDESK
Management Suite 2016” go to: https://community.ivanti.com/docs/DOC-39855.)
Mobile Devices Supported

Management Suite 2016 supports management of Apple iOS devices with OS versions of 7.0 and above, and
Android devices with OS versions of 4.0.3 (API15) and above. (Currently mobility does not support Apple DEP
or VPP, nor Windows phone devices.)
Mobility settings
Mobility settings are configured in the Agent settings tool. In Agent settings > Mobility > Security, you find
options to enable passcode settings, including setting complexity requirements which set a minimum password
length as well as setting a policy for locking the screen after a set amount of time, and setting the maximum
number of failed password attempts before wiping the device. Configuration settings will vary depending on
whether interfacing with an iOS device or an Android device.
In Agent settings > Mobility > Mobile Connectivity, you can configure enabling certificate settings, as well
as how mobile devices can connect via Wi-Fi. Setting are available to configure authentication, as well and
protocols to use as well as trusted certificates for iOS devices.
In Agent settings > Mobility > Exchange / Office 365, you can configure activity with iOS devices from the
Exchange server. This includes interfacing via an account name to a select server, whether to use the email
address from Active Directory to log in, and the number of past days of mail to synchronize.
Software Packages for Mobile Devices

Mobility management in Management Suite 2016 includes ability to deploy software to both iOS and Android
devices. This can be done by having the mobile devices receiving from a Manifest URL, or from the App store.
The apps from the App store must be free (that is: have a $0.00 cost) in order for the user to download them to
the device. (We will use software packages for mobile devices in a hands-on way when we cover the Software
Distribution section.)
There is a hands-on exercise for building a software package for mobile devices.
Inventory for Mobile Devices

Mobility management in Management Suite 2016 includes ability to receive the inventory of the managed
device. All the inventory is added to the database making it reportable and able to be queried.
Configuring Macintosh Agents

You can use Management Suite to manage Macintosh distributions. For information on “How to Install the
LANDESK Macintosh Agent”, see the Ivanti User Community at:

Configuring Linux and UNIX device Agents
You can use Management Suite to manage supported Linux/UNIX distributions. For information on Linux/UNIX
please see the Linux/Unix Landing Page on the Ivanti User Community at:
Agent Health
Agent Health is a method to ensure that the Management Suite agent running properly on installed Windows
client systems. It is designed to put the Management Suite agent back to a working state if it is not in a working
state. It is the answer to questions like:
 How do I ensure agents are running properly?
 How do I invoke self-healing on damaged agents?
 How do I reduce the need to reinstall agents?
Agent Health Technology
1. Core Server downloads LANDESK 10.0 Agent Health vulnerability definitions and remediations using the
Download Updates tool.
2. Create an Agent Health agent setting which can be used by managed devices.
3. Schedule the Agent Health agent setting to be copied to managed devices.
4. Client periodically runs Vulscan.exe to apply the Agent Health setting on managed devices.
Steps to Enable Agent Health

The steps to enable Agent Health are:
1. Download the vulnerability definition for LANDESK 10.0 Agent Health using Download Updates.
2. Create an Agent Health agent setting defining components and settings to apply.
3. Schedule the Change Setting to apply the Agent Health on the managed device.

Downloading the Agent Health Vulnerability Definition
Agent Health consists of a collection of vulnerability definitions, obtained through Download Updates. The
vulnerability definitions can then be scanned and remediated on managed devices using Vulscan.Exe. To
download the Agent Health definitions, the LANDESK 10.0 Agent Health checkbox must be selected.
Once Agent Health vulnerability definitions are downloaded, they are listed in the Patch and Compliance tool,
in the Predefined groups section.
The vulnerability definitions will only detect and repair the agent if the version matches the core server version.
Previous version definitions cannot restore the Management Suite Agent.
Create the Agent Health Agent Setting

The Agent Health agent setting lets you identify which components and setting to apply when the repair of the
Management Suite Agent occurs.

General
The general page allows you to name the agent health setting. You can set global behavior overrides for
autofix, and reboot. You can also optionally designate the setting to be the default.

Components
The components page allows you to select which components to install.
The component column identifies the agent component. The install state column designates how to treat the
component. Install state options include:
 Do nothing: Leave the component as is, whether it is installed or not.
 Install: Make sure the component is installed and stays installed.
 Remove: Removes the component if it is installed. This deactivates the component on the managed device
without deleting the files associated with the component. (The remove option is NOT available for the Base
agent component.)

Enforcement
The enforcement page has two sections:
The top section is where you designate the vulnerability definition group to use to apply agent health. You can
click the checkbox to “automatically remediate any issues found after scanning”, which will immediately act
upon the managed device to apply the agent health, if needed, at the time of the scan.
The bottom section is where you set the schedule Vulscan.exe will use to implement agent health.

Settings
The Settings page lets you select the agent setting to apply to the specific components.
Items populate on the settings page based upon what is set to install on the components page. (If nothing
appears then nothing is set to install.)
Set the desired agent setting for the desired component. You can edit and configure agent settings from here.
Schedule the Change Setting to apply the Agent Health on the managed device
In order for Agent Health to repair a managed device, Vulscan.exe needs to run and the vulnerability definition
for Agent Health must be included in the scan.
To set Agent Health to periodically run on the managed device:

1. In the Management Suite Console and open the Agent settings tool, be clicking Tools (or Toolbox) >
Configuration > Agent settings.
2. Click the change settings icon on the toolbar.
3. Name to task. (Maybe, Apply Agent Health is an appropriate name.)
4. On the Change settings page, select the Agent health agent setting you want applied.
5. Designate the desired targets to receive the task.
6. Schedule the task.

Agent Health Additional Information
Agent Health works on Windows devices only. It repairs missing files, and updates old files. It works by
launching Vulscan.exe to apply an agent setting defining the Agent Health parameters. If Vulscan.exe is
deleted, LandeskAgentBootstrap.exe will repair it when it runs. To see how healing occurs, look at each rule in
the vulnerability definitions for Agent Health. The implementation schedules agent health to occur periodically.
To manually launch the task the local scheduler runs launch the following:
C:\Program Files (x86)\LANDesk\LDClient\vulscan.exe /group=[group_name] /fixnow
There is are exercises for implementing Agent Health.
Agent Watcher
Agent watcher is a tool to ensure that the Management Suite agent is installed and running properly on
managed devices. If something goes wrong, agent watcher will act to get the device back to a working state.
Note
Best Known Methods suggest using LANDESK 10.1 Agent Health to restore the Management
Suite Agent on a managed device. Agent Health has proven to be more effective in repairing the
If a device needs to be made healthy, Vulscan.exe runs a set of LANDESK definitions and remediates the
client so the agent is restored to a working state on the managed device.
Agent Watcher settings determine which files and services are monitored and how often. You can also select
whether the utility will remain resident on the managed device.
To create Agent Watcher settings, click the Agent watcher settings icon on the Agent Configuration tool.
This opens a Setting List, where created Agent Watcher settings are listed. If the desired choice is not there,
or if you want to create a new setting, click New. That opens the Agent watcher settings window.

 Name: Type the desired setting with a unique name.
 Agent watcher remains resident: Selects whether to have LDRegwatch.exe (the Agent Watcher
executable file) remains resident in memory on the managed device all of the time. If you do not select this
option, LDRegwatch.exe will load, check for the services and files, and close (exiting memory) until the
next scheduled interval.
 Monitor these services: Selects the critical services you want to monitor with this Agent Watcher setting.
 Monitor these files: Selects the critical files you want to monitor with this Agent Watcher setting.
 Polling interval: Specifies how often you want Agent Watcher to check for the selected services and files.
 Check for changes to these settings on the core server: Specifies whether to compare the current
version of the selected Agent Watcher setting on the core server matches the one deployed to target
devices (at the Interval specified). If selected, and if settings have been modified since the last check, the
new Agent Watcher settings are set on the managed device and the Agent Watcher is restarted with the
new settings.
o Interval to check: Specifies the time period of the recurring comparison of Agent Watcher settings.
When configuring Agent Watcher settings, do NOT select services you do not intend to install on target
devices. Otherwise the core server will receive alerts for services purposely not being installed.

Troubleshooting the Agent Installation
When the Agent is installed, log files are created in the hidden folder C:\ProgramData. If you look in
C:\ProgramData\LANDesk\Log\ directory you can find the AdvanceAgent.log file (if you installed utilizing the
Advance Agent). The agent installation is captured in the wscfg32.log whether pushed, pulled, or initiated via
the advance agent.
When the Scheduler service is used for a push distribution, the C$ share is used by elevating rights via a
running service. If the push fails, try to map a drive from the Core Server to the managed device using the C$
share using the password set in the Alternate credentials portion of the Change Login window of Scheduler
tab in Configure Services.
Management Suite best known methods suggest using LANDESK 10.0 Agent Health to restore the
Management Suite Agent on a managed device. Agent Health has proven more effective in repairing the

Management Suite Agents Check for Understanding
1. How does Client Certificate-based Security work, and how does this differ from the Public-Key
Infrastructure security implemented on the Core Server?
2. What additional steps does the Management Suite Administrator need to complete when Client Certificate-
based Security is enabled in Management Suite 2016? Where does the Administrator complete these
actions?
3. Where are Client-side Certificates stored on the managed device? When and how are they generated?
4. What are Self-Electing Subnet Services, what technologies are supported, and what impact does this have
in the Management Suite enterprise?
5. How are new networks added into the Self-electing subnet services tool, and how do you set the desired
state of self-electing subnet services on newly added networks?
6. Which agent setting configures the settings for managed devices concerning self-electing subnet services?
7. What is Agent Health, and how is it implemented (downloaded, updated, and configured) in Management
Suite 2016?
8. What mobile device operating systems does Management Suite 2016 support with mobility management?
9. Which server is the Mobile Device Management (MDM) server in the Management Suite 2016
environment, and how is it set up?
10. Where do you configure the settings for mobility management?

Remote Control
Module Objectives
In this Remote Control section, you will discover:
 Cite solutions Management Suite Remote Control Provides

 Outline Remote Control Security for Console Users
 Outline Remote Control Architecture
 Use Remote Control HTML 5
 Configure Remote Control Settings on Managed Devices
 Use Remote Control Legacy Version
 List Remote Control Viewer commands
 Implement Remote Control with a Cloud Services Appliance
 Generating Remote Control Usage Reports

Solutions Management Remote Control Provides
An end-user calls the helpdesk with an issue. The helpdesk is having trouble grasping what the end-user is
attempting to describe. Or, conversely, the helpdesk understands the issue exactly and is having trouble
getting the end-user to follow the steps that will resolve the issue. Such occurrences are common-place.
Factor in the time it takes to resolve an issue where the helpdesk technician leaves his or her desk, goes to the
end-user’s location, physically sits down at the end-user’s device and fixes the issue, and then has to go back
to his or her desk. (Not to mention that while the helpdesk technician attempts to return to his or her desk, the
entire route is a series of detours which begin with the dreaded phrase, “Oh, while you’re here, this has been
happening on my PC . . .”) Such is a common theme in the daily life of a helpdesk technician.
Remote Control is an ideal way to resolve end-user issues in an immediate, direct, timely, and efficient
manner. One such company estimated that they were able to answer nine (9) times the helpdesk calls with the
implementation of Management Suite. (And the tool most often used in that month of data keeping was
Remote Control.)
An additional benefit of Remote Control is it provides the helpdesk technician the ability to teach the end-user
how to resolve the issue, eliminating the need to call the helpdesk again, should that issue recur. (Remember
the saying, “If you hand a man a fish, you feed him for a day; but if you teach him to fish, you feed him for a
lifetime.”)
Remote Control Security for Console Users

With such a far-reaching and prevailing tool as Remote Control, it is imperative that it have proper security.
(We don’t want just anyone using Remote Control to affect a managed device with more rights than the user
has!) To properly secure Remote Control Management Suite has rights that must be granted to a Console user
to enable user ability to leverage Remote Control.
The right to the Basic web console is as follows:
The rights managing the Remote Control tool are as follows:
To allow a user to launch Remote Control, that user needs to be granted Management Suite Console access,
and must be given specific Remote Control rights. The minimum rights that must be granted a user to user the
Remote Control tool are the Remote control View and Edit rights. To allow a user to utilize other Remote
Control features (Chat, Execute programs, Reboot, and Transfer files) corresponding Edit rights must be

granted to the user as well. (To grant all Remote Control rights to a user, click the X of Remote control tools
to change it to a checkmark.)
In addition to granting a user Remote Control rights is the ability to limit Remote Control access to specific
hours of the day. This can be done in the User Management tool, where access and rights are granted by
selecting RC time restrictions and making settings there.
Remote Control Architecture

In order to connect a Remote Control session a viewer from the device initiating the remote control session
must connect to an Agent (the LANDESK Remote Control Service) on the device being remotely controlled.
Remote Control settings place the configuration and settings on the managed devices as a part of the
deployment process of the Management Suite Agent.
Remote Control Session Requirements

In order for a conventional Remote Control session to initiate on a remote device, the remote device must have
the Remote Control agent installed.
In addition to the Console and remote device having the software required, the following must be in place:
 The person using Remote Control must have Remote Control rights granted to their LANDESK user
account

 TCP port 9535 must be open on the firewalls between the console and the remote device for conventional
Remote Control.
 TCP port 4343 must be open on the firewalls between the initiating device and the remote device for HTML
Remote Control.
 TCP port 443 must be open on the firewalls between the console and the Cloud Services Appliance, and
the end user and the Cloud Services Appliance, for remote control using the Cloud Services Appliance.
HTML 5 Remote Control

HTML 5 remote control uses an internet browser application as the remote control viewer. This removes the
requirement of installing a browser or using a browser plugin if the Administrator wants to initiate a remote
control session from a Web Console. This makes it possible for an administrator to start a remote control
session on HTML5 enabled devices and leaves the device with no need to uninstall a viewer or browser plugin.
HTML 5 Remote Control can occur on any HTML5 compatible browser, including:
 Windows PC: Chrome, Firefox, Internet Explorer version 9 or later, Safari, and Opera
 Macintosh OS X: Safari, Chrome, Firefox
 iOS and Android mobile devices
 Linux: Default browsers for Gnome and KDE
When compared to classic Remote Control, HTML Remote Control uses more bandwidth, as well as more
CPU. If using HTML Remote Control over a slower link, it is recommended that you implement performance
settings. (See the Performance Settings in the HTML toolbar.)
After updating an agent to include HTML Remote Control, an updated inventory scan must be received in order
to initiate HTML Remote Control. As additional ability of HTML Remote Control is the ability to allow multiple
viewers to view the same managed device.
In order to enable HTML remote control on the managed device, the remote control setting deployed to the
device must be set to allow HTML access. This is selected by checking the Allow HTML access checkbox on
the General settings page of the Remote control settings.

Starting an HTML Remote Control session
You can launch an HTML Remote Control session from either:
 The Management Suite Console / Remote Control Viewer: Right-click a managed device and click
HTML remote control.
 An HTML Browser: Open a browser and enter the URL https://<device names or IP address>:4343
 Note: A video on using HTML5 Remote Control in Management Suite can be viewed at:
https://www.youtube.com/watch?v=8hMmg4rUCng
Since there is no console installation, and HTML 5 remote control can be initiated from various devices,
security must be assured. So when HTML 5 remote control is initiated, a screen prompts for security
identification prior to allowing the remote session to connect.

Using the HTML Remote Control Window
When HTML Remote Control is initiated, you will need to provide credentials for a user who is authorized to
use Remote Control. When the login is complete, the HTML remote control session viewer loads. Here is what
this looks like.

The toolbar at the bottom has the following controls:
 Keyboard: If remote controlling in from a device which does not have a keyboard, such as a tablet or
phone, the keyboard key toggles on a keyboard to bring ability to press keys to pass to the remote device.
The ctrl-alt-del key is in the upper left corner. The Ctrl, Alt, and Shift keys are sticky, and will remain
clicked until clicked again. (When the key is active, it will turn a darker shade of gray.) If the remote
controlling device is a device with its own keyboard, the keyboard key toggles on keys to use at the top,
above the screen. The Windows key and Function keys are made available, amongst other keys.
 Screenshot: This hits [Print Screen] and allows you open or save the .png file to device initiating remote
control.
 Monitors: This enables the ability to view multiple monitors one at a time, or as a whole (if the remote
device has multiple monitors). The multiple monitors thumbnail views let more easily choose which monitor
to view.
 Tools: This brings up tools to Remote Execute, File Transfer, Restart, or Chat.

o Remote Execute: Here you can type the file name you want to execute, or browse to the file you want
to execute and hit [Run].
o File Transfer: Here you can select a directory on the remote machine and use toolbar icons to Upload,
Download, New Directory, Delete, and Up one level, to copy to or from the remote machine.
o Restart: Reboots the remote device (if the remote device is set to allow reboot).
 Notification timeout (seconds): Sets a countdown, in seconds, until reboot (30 is default).
 User message: This field contains what message will appear with the countdown to reboot.
 Shut down computer: Select this radio button to shut down the remote device.
 Restart Computer: Select this radio button to restart the remote device.
 Restart and reconnect: Select this radio button to restart and reconnect the Remote Control
session with the remote device.
- Reconnect timeout: Sets the amount of time, in minutes, to wait before reconnecting the
Remote Control session when restart and reconnect is triggered (5 is default).
 [Restart]: Starts the shutdown, restart, or restart and reconnect, which ever was selected.
o Chat: Here you can click a button to Start Chat which allows you to chat back and forth. The
messages have a time stamp, and there is ability to save chat sessions.
 Clipboard history: This displays a File List or Text List with icons to Clear List and Transfer selected text
to my clipboard. This enables a copy from the remote device to paste to the local device.
 Settings: This displays the settings dialog includes the following settings:
o General Settings: which include settings to:
 Blank Screen: Enabling this hides the remote screen so the activity can only be seen by those on
the viewer side.
 Lock out keyboard and mouse: Checking this disables the keyboard and mouse on the remote
device, giving sole use of the keyboard and mouse to the person performing the Remote Control
session.
 Auto-hide Menu Bar: Checking this hides the HTML toolbar during the Remote Control session.
 Use alternate names: Allows typing the operator name and device name performing the remote
session. The purpose here is to identify the viewer side operator name and device name, if
through naming convention the user name and/or device name is unclear to the person whose
device is being remotely controlled. This can also be used if there is a desire to not reveal the
actual name of the operator or device that is initiating the remote control session.
- Alternate name: Field where the person initiated the remote control session types the name
to appear to the remote side end user
- Alternate computer name: Field where the person initiated the remote control session
types the computer name to appear to the remote side end user
 Keyboard Language: Where you can select the language of keyboard on the local side.
o Performance Settings: which includes settings to:
 Use Mirror: Checkbox turning the mirror driver on or off (unavailable if the mirror driver is enabled
already in the Remote Control Agent Setting).
 Suppress Wallpaper: Checkbox turning the mode on or off
 Grayscale Mode: Checkbox turning the mode on or off
 Bits Per Pixel: Bits per pixel setting reduces the amount of color that is transmitted over the link,
thus decreasing the data transmitted overall. The maximum setting is 15 bits per pixel. Other
settings available are 12, 9, and 6. When the person viewing the remotely controlled device
reduces the color depth, he or she will notice color changes.
o Hotkey Settings: Show settings which can be invoked or changed. Available settings include:

 Close viewing session: Ctrl+Alt+S
 Send Ctrl-Alt-Delete: Ctrl+Alt+D
 Send Ctrl-Esc: Ctrl+E
 Refresh screen: Ctrl+Alt+R
 Restart computer: Ctrl+R
 View Monitors: Ctrl+Alt+V
 Print Screen: Ctrl+Alt+P
 Screen Capture: Ctrl+Alt+C
 Zoom: This toggles a zoom mode. When zoomed out, the remote session will be scaled to fit the viewer
window. If the window size is too small, the scaled text, and other screen contents, can be too small to see.
When zoomed in, scroll bars let the viewer choose which portion of the remote screen to see.
 Exit: Closes the remote session.
 Help: Brings up Ivanti help files.
Using HTML 5 Remote Control from a Mobile Device

If using HTML Remote Control from a mobile device, a larger screen devices work better. Mobile devices have
slower CPUs than desktops or laptops, so the sessions have a slightly slower frame rate. The best practice
would be to enable all the performance settings in the HTML tool bar, on the Performance settings tab.
Remote Control Settings

There are multiple ways to configure Remote Control Setting configuration settings.
One way is using the Agent settings tool. To open the Agent settings tool in the Management Suite Console,
click Tools > Configuration > Agent settings > Remote Control.
Another way is to configure the setting in the Agent configuration tool. To open the Agent configuration tool in
the Management Suite Console, click Tools > Configuration > Agent configuration. Once in the tool, open
an Agent configuration, click Remote control, and click [Configure]. The Configure remote control setting
window opens with options to create a new remote control configuration (by clicking [New]) or edit an existing
configuration (by clicking [Edit]).
You are then presented with options for General settings, Indicator settings, Permission settings, Security
settings, and Session settings.
 Remote control:
Set configuration settings to apply as a Remote Control setting on managed devices.
o General settings: On this page, you can set and select the following:

 Name: Type the desired name of the Remote Control setting.
 Allow HTML access: Select whether to install the HTML access remote control on the managed
devices.
 Allow legacy remote access: Select whether to install the legacy remote access remote control
on the managed devices.
 Allow: Select whether to allow the following:
 Remote control: Select whether to be able to view the screen and interact using keyboard
and mouse on the remote device.
 Draw: Select whether to be able to use the draw feature on the remote device. (This requires
remote control to be selected.)
 View only: View the screen but not have keyboard and mouse functionality on the remote
device. (This requires remote control to be selected.)
 Restart: Select whether to be able to remotely restart the remote device.
 Run programs on remote device: Select whether to be able to run programs (launch
applications) on the remote device.
 Run as administrator: Select whether to run programs launched during the remote session
as administrator.
 File transfer: Select whether to be able to transfer files to or from the remote device during
the remote session.
 Set as default: Select whether to have this setting as the default when deploying the
o Indicator settings: On this page, you can select the following remote control indicators:

 Floating desktop icon: Select whether to display an icon on the desktop of the managed device.
- Only visible during remote control: The display icon will appear on the screen of the
confirmation when someone is viewing them. When the session is ended the icon will
disappear.
- Always visible: The listening ear display icon will appear on the background of the
remote desktop when the LANDESK Remote Control Service (ISSUSER.EXE) is running
on the managed device, and the device is NOT being remotely controlled. When the remote
control session is started, the listening ear icon is replaced with a remote control icon.
That icon will remain until the remote control session ends, at which point the icon will change
back to the listening ear icon.
 System tray icon: Select whether to display an icon in the system tray on the managed device.
- Only visible during remote control: The display yellow highlighted remote control icon
will appear on the system tray of the remote desktop only during the remote control session,
giving the end user visible confirmation when someone is viewing them.
- Always visible: If selected, the remote control icon with a person appears in the system
tray when the LANDESK Remote Control Service (ISSUSER.EXE) is running on the
managed device, and the device is NOT being remotely controlled. When the remote control
session is started, the remote control icon with a person is replaced with a remote control the
icon surrounded in yellow. That icon will remain until the remote control session ends, at
which point the icon will change back to the remote control icon with a person.
o Permission settings: Select the following permission settings for the Remote Control setting:

o Permission not needed, full access: Select this setting to NOT request permission of the end-
user to start a remote control session on the managed device.
o End user must grant permission and must be logged in: Select this setting to require the end-
user to grant permission to start a remote control session on the managed device. If the user is
logged out, a remote session cannot be initiated with the managed device.
o End user must grant permission, but only if they are logged in: Select this setting to require
the end-user to grant permission to start a remote control session on the managed device. If no
one is logged in, the remote session is allowed, but since the screen will be at a login prompt, the
person initiating the remote control session will have to know a password to gain access to the
device.
o End user must grant permission: Select this setting to send a request dialog to start a remote
control session on the managed device. A remote control session is not allowed unless permission
is granted.
o Display a custom message: Select whether to prompt the user on the managed device with a
custom message to ask permission to initiate Remote control, Chat, Remote execute, File
transfer, Restart, or All permissions. The custom message is typed in the subsequent field.
o Ask permission to use all features at one time: Select whether to ask once per remote session
for all features allowed during the remote control session. If unselected, request dialogs will be
sent to use each feature during each remote control session.

o Close permission message box after: Sets the number of seconds to display the request to
initiate a remote control session. If permission is not granted by the end user on the managed
device within the specified time frame, the request closes without permission being grated to
initiate the remote control session.
o Security settings: On this page, you can select the following remote control security settings:
o Local template (least secure): Select to grant ability to any person initiating a remote control
viewer to initiate a remote control session. Any of the settings granted on the General settings
page will be able to be utilized during the remote control session. This setting does not verify if the
user is a member of a specific group, has the remote control viewer from a specific Core Server,
or any other verification of security. Hence it is the least secure setting.
o Windows NT security / local template: Select to limit the person initiating a remote control
session to be a member of the Remote Control Operators group, which is installed on the
managed device when the remote control setting is placed on the managed device. Members of
the Remote control operator groups can view and interface using the keyboard and mouse
during the remote control session. Member of the View only group can only view the display
during the remote control session. Use the [Add] and [Remove] buttons to add members to the
two groups.
 Smart Card Required: Selects whether to require a hardware SmartCard reader on the
device initiating remote control sessions. When a remote device’s agent requires SmartCard
for remote control, the session will not start unless a SmartCard is inserted and the
SmartCard PIN is provided. The SmartCard user must also be in the Remote Control
Operators or View Only group.
SmartCard security only works on Windows 7 or newer devices. SmartCard authentication
also requires the Windows remote control viewer application. HTML remote control does not
support SmartCard authentication.

o Integrated security (most secure): Select to use the PKI keys to authenticate for permission to
perform a remote control session. The integrated security model is the most secure option and it
therefore the default method. Under the integrated security model, the Management Suite SSL
keys (certificates) are utilized. The communication occurs as follows:
1. Remote Control Viewer from the Console contacts the Core Server, and the SSL public key on the
Console device proves a match with the private SSL key on the Core Server, and that the User has
Remote Control Rights, and passes the IP Name (or IP Address) of the device to be Remotely
Controlled.
2. Core Server validates the IP Name and IP Address in the database.
a. If the IP Name passed resolves (via DNS) to the same IP Address listed in the database, the
Remote Control process continues.
b. If the IP Name passed does NOT resolve to the same IP Address listed in the database, a
message is sent to the Console User stating the Name and Address do not resolve the same,
and if the Remote Control process is to continue, to click and continue the process. (In this case,
IP Address in the database is the device contacted by the Core Server to continue the Remote
Control process.)
3. The Core Server proves a match with its private SSL key to the public SSL key on the Managed
Device and passes a token (16-byte code generated at random, with a 30-second life) to the Managed
Device.
4. The Core Server passes the same 16-byte token to the Remote Control Viewer.
5. The Console uses the Remote Control Viewer and generated token to Remote Control the Managed
Device.
The three-legged communication is required because the Core Server is the only device with the
Private SSL key. The Console only has the Public SSL key. If the Core Server happens to be down,

Remote Control using the Integrated Security model is not possible, because the SSL authentication
and generation of the token cannot occur.
o Session settings: On this page, you can select the following remote control session settings:
o Lock the remote computer when session ends: Select to lock the managed device to a secure
mode once the remote control session ends.
o Terminate remote access if the user logs out or locks the machine: Select to automatically
end the remote control session if the end user logs out or locks the managed device.
o Allow the end user to terminate the session: Select to allow the end user on the managed
device to access end the Remote Control session. The end user can access the remote control
desktop icon or the remote control system tray icon to stop the active remote control session. If
this option is not selected, the end user of the managed device cannot stop and active session
through either icon.
o Close inactive session after: Sets the time period to automatically end the remote control
session of there is no keyboard or mouse activity. Set the time to 0 to disable this feature.
Remote Control Options

Remote Control Settings (deployed as a part of the Management Suite Agent) place configuration settings
used by the LANDESK Remote Control Service (ISSUSER.EXE) on the managed device. The Remote Control
settings and security options are placed on the Managed Device in the registry. The location in the registry is
as follows:
32-bit Windows devices: HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDESK\WUSER32.
64-bit Windows devices:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\LANDESK\WUSER32.
Setting placed in the registry are as follows:

Allow Chat: Grants permission to chat with the remote device. (0 is off, 1 is on.)
Allow Draw: Grants permission to use the viewer window’s drawing tools on the remote device. (0 is off, 1 is
on.)
Allow File Transfer: Grants permission to transfer files to and from the remote device’s local drives. (0 is off, 1
is on.)
Allow HTML Access: Grants permission to use HTML remote control on this device. (0 is off, 1 is on.)

Allow Reboot: Grants permission to reboot the remote device. (0 is off, 1 is on.)
Allow Remote Execute: Grants permission to launch items on the remote device. (0 is off, 1 is on.)
Allow Remote Execute As Admin: Grants permission to launch items with Administrative privileges on the
remote device. (0 is off, 1 is on.)
Allow Takeover: Grants permission to initiate Remote Control on the remote device. (0 is off, 1 is on.)
Allow User Terminate Session: Grants permission to the User to terminate the Remote Control session. (0 is
off, 1 is on.)
AllowPreviousProtocol: Grants ability to alternate the mode of Remote Control from Direct Mode (directly
with the Core Server) to use Remote Control settings with the Cloud Services Appliance mode. (0 is off, 1 is
on.)
Always Visible: Will show the Remote Control desktop icon while the Remote Control service is loaded. (0 is
off, 1 is on.)
Bits Per Pixel: Is a setting for HTML Remote Control. (6 takes fewer colors and less bandwidth than 15.
Setting include 6, 9, 12, and 15.)
BlankingDriver: Specifies whether the screen blanking driver is installed or not. (0 is off, 1 is on.)
Custom Chat Notification: Designates the message to appear to begin a custom chat notification dialog.
Custom Default Notification: Designates the default message to appear in a notification dialog.
Custom File Transfer Notification: Designates the message to appear in a file transfer notification dialog.
Custom Reboot Notification: Designates the message to appear in a reboot notification dialog.
Custom View Notification: Designates the message to appear in a custom view notification dialog.
DisconnectOnLogout: Specifies whether the remote control session should disconnect if the remote user logs
out. (0 is off, 1 is on.)
InactivityTimeoutMinutes: Specifies the number of minutes of inactivity (mouse movement or keyboard
entries) before the Remote Control session will automatically end. (0 means the Remote Control session will
not end due to inactivity.)
InstallViewOnlyGroup: Specifies whether a View Only Group is installed to be used, as a part of the Windows
NT security setting. (0 is off, 1 is on.)
Lock Machine: Locks the remote machine to require login credentials when the Remote Control session ends.
(0 is off, 1 is on.)
Manage NT Group Members: Specifies whether to validate NT group membership when starting a Remote
Control session.
MirrorDriver: Specifies whether or not the Mirror Driver is enabled during a Remote Console session. (0 is off,
1 is on.)
Modify Settings: specifies whether settings can be modified. (0 is off, 1 is on.)
Permission Required: Designates whether the end-user must grant permission to begin a Remote Control
session. (0 is Permission not needed, full access, 1 is End user must grant permission and must be logged in,
2 is End user must grant permission, but only if they are logged in, and 3 is End user must grant permission.)
Request Permission Timeout: Sets the number of seconds a permission dialog will remain open when
initiating a Remote Control session which requires end-user permission.
Security Type: Designates the security model 0 = Local Template, 2 = Windows NT / Local Security, 9 =
Integrated Security
Single Permission: Works when Permission Required is enabled, and designates whether permission must
be granted for each Remote Control action, Remote Control, Chat, Remote Execute, File Transfer, or Reboot.
(0 is off, 1 is on.)
Smartcard Required: specifies whether or not a hardware SmartCard reader is required on the device
initiating remote control sessions. When a remote device’s agent requires SmartCard for remote control, the
session will not start unless a SmartCard is inserted and the SmartCard PIN is provided. The SmartCard user

must also be in the Remote Control Operators or View Only group. SmartCard security only works on Windows
7 or newer devices. SmartCard authentication also requires the Windows remote control viewer application.
HTML remote control does not support SmartCard authentication. (0 is off, 1 is on.)
System Tray Always Visible: Designates whether or not to show the Remote Control icon in the taskbar while
the LANDESK Remote Control Service is running. (0 is off, 1 is on.)
System Tray Remote Balloon Notify: Designates whether or not to show the Remote Balloon Notify. (0 is off,
1 is on.)
System Tray Visible Signal: Designates whether or not to show the Remote Control icon in the taskbar while
the Remote Control session is running. (0 is off, 1 is on.)
ViewOnly: Designates whether or not the User initiating Remote Control can use the keyboard and mouse, or
can just view (0 is full interaction, 1 is View Only.)
Visible Signal: Designates whether or not the Remote Control icon will be shown during the Remote Control
session. (0 is off, 1 is on.)
Remote Control Legacy Version Implementation

Remote Control has always been a part of Management Suite since it was first introduced over three decades
ago. The non-HTML version is now referred to as the Legacy version. This version requires initiating Remote
Control from the Console on the Core Server, or the Remote Console, installed on a desktop or laptop
computer, or from a Web Console.
Starting a Legacy Remote Control session from a Console

To start a Legacy Remote Control session from either the Console on the Core Server, or a Remote Console:
1. In the Network view, locate the device with which you want to initiate a Remote Control Session.
2. Right-click the device, and click Remote Control. (A box appears with options to use Remote Control,
Chat, File Transfer, Remote Execute, or Reboot.
3. Click Remote Control.
4. The remote viewer loads and the Remote Control session initiates.
Starting a Legacy Remote Control session from a Web Console

To start a Legacy Remote Control session from a Web Console, the Remote Control Viewer must be installed.
The first time a device launches a Remote Control Session from the Web Console, the user will be prompted
the install the Viewer.
With the Remote Control tool installed, the Remote Control session can now be initiated. In the Add or Remove
Programs view you will then find the “LANDESK® Software Remote Control Console”.
Remote Control Viewer Installation

The steps to install the Remote Control Viewer are as follows:
1. Launch the Web Console.

(Open a web browser to http://Core Server name or IP Address/remote)
2. Launch Remote Control.

(This can be done by clicking the Remote Control icon in the toolbar, typing the name or IP address of the
machine and clicking [Launch] OR by right-clicking a device in the All Devices list, and clicking Remote
Control.)

3. If the Remote Control Viewer is not yet installed, a window will open stating the viewer is not yet
installed.
4. If the browser is set to not allow execution or installation of add-ons, the browser will indicate the
“LANDESK® Software Remote Control Console” must be installed.
5. Click to allow the browser to initialize the installation.
6. When the Security Warning window asks if you want to install the software, click [Install].
7. The installation occurs and Remote Control initiates. Now that the Management Suite Remote Control
Console is installed, it will be reflected in Add or Remove Programs.
Legacy Remote Control Viewer Options

The Legacy Remote Control Viewer menu offers the following options:
 File: The file selection offers the following options:
o Start connection: To start the session. (If the session is already started, this option is unavailable.)
o Stop connection: To end the Remote Control session
o Save connection message: To save to a file the connection messages generated from the Remote
Control session.
o Exit: To end the Remote Control session.
 View: The view selection offers the following options:
o Toolbar: To select whether to view and access the toolbar (under the Remote Control Viewer menu).
o Status Bar: To select whether to view and access the Status Bar on the remote device.
o Connection messages: To select whether to view the Connection messages while connecting to the
remote device as the Remote Control Session starts and continues. (This is helpful for
troubleshooting.)
o Full Screen (Ctrl-Alt-M): To toggle the Remote Control Viewer in and out of Full Screen mode.

 Tools: The tools selection offers the following options:
o Remote Control: To initiate remote access of the remote device.
o Chat: To initiate the chat tool to work between the viewer and the remote device.
o File Transfer: To initiate the file transfer tool to copy of move files between the viewer device and the
remote device.
o Reboot: To initiate a reboot on the remote device.
o Draw: To initiate the draw tool on the remote device. Draw includes a laser pointer, a tool to draw in
various colors, with various line thicknesses, and highlighting capabilities.
o Options: The options selection offers setting on three tabs: Change settings, Optimize
performance, and Hot key settings.
Change settings tab in Options
Allow Autoscroll
When the Viewer connects with the remote device, the screen is automatically sized into the Viewer window. In
many cases, this is the desired effect. But, if the remote side screen has multiple monitors, and a setting that
has a much larger aspect ratio than that of the Viewer side, seeing the remote screen on the Viewer side is not
feasible. So in those cases, switch off the autosize feature, and use the Autoscroll feature.

The Autoscroll feature enables the Viewer window to scroll as the cursor is moved closer to the window border.
The closer you move to the border, the faster the scrolling occurs.
Lockout the Remote Keyboard and Mouse

This feature allows the Viewer side user to lockout the keyboard and mouse on the remote device side. This
can be helpful to get the attention of the user to teach, or simply to override and resolve an issue, performing
the necessary steps without remote side user interference.
This feature is a toggle, which can be enabled and disabled (By using “CTRL-Alt-K” or by checking the box).
When the remote control session ends control will automatically be granted back to the remote side end-user.
Note that special key combinations in Windows such as “CTRL-ALT-DEL” or the “Windows-Key+L” are not
locked out.
Synchronize Clipboards to Paste between Local and Remote Keyboards

This feature allows the Viewer side to copy from the remote device and paste to the Viewer side. This is
especially helpful when capturing error messages or information windows from the remote device.
Hide the Remote Computer Screen

This feature hides the remote screen so the remote side user does not see what is done on Viewer side. For
example, if the Viewer side user wants to map a network drive, run a program, and then un-map the network
drive, all without the remote side user knowing the location of the network drive, this feature can be helpful.
It is recommended that Viewer side user warn the remote side user that the screen is going to blank-out, so the
remote side user does not power off the remote device, or some such action that would be counter-productive.
Always ask to Clear Remote Computer’s Screen when Starting Remote Control
This feature works along with the Hide the remote computer screen. This feature will blank the remote side
screen display when the remote control session is established. If user permission is required prior to
establishing the remote control session, permission will be asked, and when the remote side user clicks [OK],
the screen will then go blank.
Keyboard Mapping
Keyboard mapping is a feature of Remote Control that enables multiple language support. For example, the
Spanish keyboard has the ñ key, which corresponds to the : (colon) key on the English keyboard. If the remote
end user, with a Spanish OS presses the ñ key, the ñ is entered on the device and appears on the screen. If
the Viewer side user, with an English OS presses the : key, the : is entered on the remote device and appears
on the remote screen. (Prior to keyboard mapping feature, the Viewer side user would press : and the ñ would
appear on the remote side device, which made searching the internet difficult . . . httpñ// does not search well
in a browser.)
The technology that enables this feature is built into the Remote Control Viewer and the Remote Control
Agent. The Remote Control Viewer translates the keystrokes to Unicode and transfers the Unicode characters.
The Remote Control Agent translates the Unicode characters back to keystrokes based on the remote device’s
keyboard mapping table (which is based on the local language setting of the operating system).
The benefit of keyboard mapping is that it automates Remote Control for mixed language environments and
requires no interaction from the end user.

Enable old agent compatibility (pre 8.5 agents)
When the remote control session is established with Management Suite agents prior to version 8.5 this option
will be made active. Selecting this will enable settings to be compatible with those that are present in the old
Remote Control.
Use Alternate Names

When the remote control session is established, if remote control permissions are enabled the remote device
permissions window appears showing the Username and Computer requesting to initiate the Remote Control
session. By default, the Username will populate with the logged in user and the hostname on the Viewer
computer. If you want the remote side user to see an alternate username and alternate computer, enter what
you want the remote side user to see in the alternate name and alternate computer fields. This option is
helpful to environments with naming conventions where usernames and computer names may not make sense
to the person granting permission to begin a Remote Control session.
Optimize performance tab in Options
Optimize performance for

Network bandwidth is crucial for Remote Control. The Optimize performance tab allows selecting settings
corresponding with the network bandwidth available. Options include: Slow connection (Modem), Medium
connection (Broadband), Optimize for fast connection (LAN), and Custom connection. Each setting uses a
combination of the three options in the Display section.

Hot key settings in Options
Hotkey Settings: Show settings which can be invoked or changed.
 Help: The help section offers the following options:
o Help Topics: To bring up the searchable Remote Control Help.
o About: To bring up version information of the LANDESK Remote Control Service.
Remote Control Viewer Commands

The Remote Control Viewer can be launched using a command-line option that immediately opens a viewer
window, connects to a specific device, and activates the viewer features (like Remote Control, chat, file
transfer, and so on).
Command-line options are launched from the C:\Program Files\LANDesk\ManagementSuite directory. The
command-line options use the following syntax:
 Isscntr /a<address> /c<command> /l /s<Core Server (name or IP Address)>
The following is a list of Remote Control Viewer command-line prompts:

/a<address> Contact a device at a particular TCP/IP address. The TCP/IP address may include both
numeric and name-style addresses, separated by semicolons. The hostname can also be
specified.
/c <command> Start the Remote Control Viewer and run a particular feature. (See the command names
below.) Multiple /c arguments can be specified on one command-line. For example:
 Isscntr /aPC123 /c”Remote Control” /c”file transfer”
Choose from these features:
 Remote Control: Open a Remote Control window
 Reboot: Reboot the remote device
 Chat: Open a chat dialog window
 File Transfer: Open a file transfer session
/l Limit the viewer interface so it only displays the features specified with /c.
/s<Core If using certificate-based security, use this option to specify the Core Server with which to
Server> authenticate. This option is helpful if using remote control in a multi-core environment.
To create a shortcut to use the Remote Control Viewer, initiating only Remote Control, on a device that you
choose by entering the hostname or IP Address uses the following syntax:
 Isscntr /c”Remote Control” /l /s<Core Server (name or IP Address)>
Example 1: To open a Remote Control window from a Core Server named “LDCore”. This will ask you to enter
the hostname or IP Address of an end-user device of your choice.
 Isscntr /c”Remote Control” /l /sLDCore
Example 2: To open a Remote Control window on an end-user device named “LDWin7”, from a Core Server
named “LDCore”.
 Isscntr /aLDWin7 /c”Remote Control” /l /sLDCore
Example 3: To open a Remote Control and chat session connecting to a device named “LDWin7” from a Core
Server named “LDCore”. If this fails, an attempt will be made to connect to the IP Address 10.20.30.40:
 Isscntr /aLDWin7;10.20.30.40 /c”Remote Control” /c”Chat” /l /sLDCore
Using Remote Control with a Cloud Services Appliance

The Cloud Services Appliance (CSA) makes it possible to initiate a Remote Control session with a compatible
device connected to the internet from anywhere in the world! This is fantastic news for administrators who have
to manage devices seldom or never connected to the corporate network. This can eliminate the need to have
remote devices connect via a Virtual Private Network (VPN). However, if a corporate VPN is needed, the CSA
makes a Remote Control session possible enabling an administrator to remotely configure the VPN client on
the remote device.

Initiating a Remote Control session using a CSA
In order for a Remote Control session to be established through a CSA, the Remote Control Agent on the
managed device must be in Gateway mode (rather than Direct mode). There are a couple of scenarios you can
implement to do this.
Scenario 1: You have a device (which is NOT configured with a Management Suite Agent) which you need to
remote control. In this instance, the person asking to be remotely controlled must run an application to load the
Remote Control service. This can be done a couple of ways:
(a.) have the user open a network browser, connect to the CSA, and load the LANDESK™ Remote assistant
client.
To have the user open a network browser, connect to the CSA, and load the LANDESK™ Remote
assistant client, do the following:
1. Have the user open a network browser, and connect to the CSA (https://<CSA name, or CSA IP
Address>). (The Cloud Services Appliance web page appears.)
2. Click Cloud Services Appliance Utilities. (The Remote assistant client web page appears.)
3. Click [Install now]. (If there are issues, you can click on RCClient.exe and Run the file.)
OR
(b.) have the user open a network browser and connect to a publicly available website your company would
have available. (In this case, you would create an .EXE file and place it on the website for users to download
and run.)
To create this .EXE to have available from a company website, do the following:
1. In the Management Suite Console, click Configure > Manage Cloud Services Appliances. (The Manage
Cloud Services Appliances window appears.)
2. Click the Remote control agent tab.
3. In the Choose an available CSA for the remote control package field, select the CSA you will use for
Remote Control sessions.
4. In the Choose which features to allow field, select the Remote Control configuration you will use for
Remote Control sessions. (If you have not yet built a Remote Control configuration you want to use, you
can click [Configure] and create a Remote Control configuration to use, and select it to use after you
create it.)
5. Click [Create]. (The Windows Explorer will open so you can save the .EXE file where you want.)
The file you create using the above steps is the one you copy to the website you company would have
available.
Scenario 2: You have a device you want to manage, so you deploy the Management Suite Agent to the device
after you have configured the Core Server to use a CSA. The Management Suite Agent you build after
configuring the Core Server to use the CSA has connection information, as well as both the Gateway mode
and Direct mode options. Devices loading the LANDESK Remote Control Service should load in the correct
mode, regardless of where they attach to a network. (When the LANDESK Remote Control Service loads, it
sends a ping packet to the Core server to see if it gets a response packet in return. If it does, it loads in Direct
mode, if it does not, it loads in Gateway mode.
Once either the file is loaded in scenario 1, or the Agent loads in Gateway mode in scenario 2, the device is
ready to be remotely controlled via the CSA.
To initiate the Remote Control session via the CSA, right-click on a device in the Management Suite Console,
and click Remote control via management gateway. (A window will open where you can enter credentials to
use the CSA for remote control. After authentication, the devices in Gateway mode will appear, and can be
selected.)

or later.
 The Management Gateway Service (which provides CSA communication).
SSL certificate set is created in the C:\Program Files (x86)\LANDESK\Shared Files\Keys directory. The old
SSL certificates are moved to the C:\Program Files (x86)\LANDESK\Shared Files\Keys\Backup\<Date and
Time> directory.
managed.

you want to manage.
mode?)
Ivanti Services window will appear stating: “The LANDESK Management Gateway Service must be
restarted before your changes will take effect. Do you wish to restart it now?)
21. If this Configure Ivanti Services window appears, Click [Yes].
22. A Configure Ivanti Services window appears stating: “You must restart the services that use the database
before your changes will take effect.” Click [OK].
Remote Control Reporting

Remote Control reports can be run, based on what is logged.
Remote Control Logging

Reporting Remote Control Activity can be a necessity for security purposes, so Remote Control Logging is
enabled by default. The Activity is saved in the Core Database, and can be exported to reports and then
incrementally deleted, by date, from the database. To incrementally delete activity from the Remote Control
Log, or to disable Remote Control logging completely, open a Console, and click Configure > Remote
Control Logging.
Remote Control Reports

To generate Remote Control reports, open the reports tool. Under Standard Reports, find Remote Control.
There are three standard reports offered there:

Remote Control History by Managed Device
Remote Control History by Operator
Remote Control Summary
Remote Control History by Managed Device:

Remote Control History by Operator:

Remote Control Summary:

Check for Understanding Concerning Management Suite
Remote Control
1. How do you assign Remote Control Settings to managed devices?
2. How do you change Remote Control settings on specific managed devices?
3. How do you implement Remote Control so that devices initiating a Remote Control session require a
SmartCard and PIN?
4. How would you limit Remote Control so a technician could only use it during business hours on weekdays?
5. What is keyboard mapping and how is it useful?
6. What are the security settings available in Remote Control and how do they work?
7. How do I set Remote Control so that an end user must grant permission for anyone with the right to initiate
a Remote Session to do so?
8. What are some differences between HTML and legacy remote control?
9. Which security setting requires the Core Server to be powered on and connected to the network for remote
control to be used, and why?

Inventory
Module Objectives:
 Cite solutions inventory offers

 List new inventory features in version 2016
 Outline the inventory scanning process
 Launch an inventory scan in various ways
 Configure inventory settings in the Agent Configuration
 Configure inventory settings in the Local Scheduler
 Use Real-time Inventory and Monitoring
 Outline how Inventory Discovers and Reports Software
 Configure the Inventory Service
 Describe the use and role of LDAPPL3 files
 Change Software in the Manage Software List Tool
 Create and Use Custom Data Forms
 Create Queries
 Troubleshoot Inventory Issues

Inventory Solution
Effective business practices strongly suggest having a database of all assets. Effective business approaches
include planning when to retire old company computers, printers, and other hardware, which necessitates
purchasing replacements. Planning and budgeting in carrying out such a business plan is far more easily done
when an updated, comprehensive, asset list is available.
At the heart of Management Suite is Inventory. The first action taken on a managed device, once the
Management Suite Agent is deployed, is to send an inventory scan of the device to the Core Server for
addition to the Management Suite database, which makes all the inventoried data present, viewable, and
searchable from a Console.
Once managed devices appear in the network view of the console, they are able to be managed and acted
upon from the Console.
Inventory listed in the Console has hardware and software components. The inventory of hardware helps track
ownership and placement of PCs, memory, peripheral hardware, etc. The inventory of software helps assure
software license compliance which is vital piece of cost containment.
Inventory, as it works in Management Suite is versatile and effective. Let’s explore its different facets and help
you be an effective resource for managing IT Assets.
New Inventory Features in Version 2016

Enhancements to inventory in Management Suite 2016 include:
Post to Web Service

The inventory scanner can send the scan to the Core Server (or other designated server receiving the scans)
via a web service using port 443, the secure socket layer port.
The business use case this resolves is eliminating the need to open TCP port 5007 on the firewall of both the
managed device sending the inventory scan as well as the server receiving the scan. (Port 443 is usually open,
even in the most secure environments.)
To set the inventory scanner to use this new feature, click the Post To Web Service option in the Agent
Inventory Setting on the Scanner settings page.

The scans are received in the postingData directory in the Default Web Site directory as shown in Internet
Information Services (IIS) Manager. The physical directory is:
C:\Program Files\LANDesk\ManagementSuite\LANDesk\ManagementSuite\Core\postingData. The

ScanInstructons directory, which also exists at the same level, has the file Web.config which directs the
service how to handle the inventory scan files.
Inventory Service Multiple Server Support

The LANDESK Inventory Server service can support multiple servers adding scans. With the Mobile Device
Management (MDM) server adding scans while the Core Server (or other designated server) adds them, a
change was made move the mutex into the database. This allows simultaneous record updates.
Inventory Service Self-Monitoring (Degradation Monitoring)

The LANDESK Inventory Server service is now equipped with technology to measure if performance degrades
while processing scans. If performance degrades below configurable thresholds, an event is triggered and the
action is logged in the Windows Applications event log.
Two new settings (configured in Advanced Settings, on the Inventory tab of Configure Services) set the
monitoring parameters.
 Degradation Sample (minutes): (Default=15) Sets the number of minutes to store data before testing it
against and adding it to the averages in the database.
 Degradation Threshold (percent): (Default=20) Percent of processing degradation before logging an
event into the Windows Applications event log.

Performance is measured to record the average times in kb/sec for:
 file Input/Output
 Database Access
 Processing (parsing)
This data is written to the Inventory Timings table in the database. If the performance drops below the
threshold, the event is triggered.
Max Scan File Size

The maximum allowable size of scan files to be processed into the database has been increased to 20 Mb,
double its previous size. Scans that exceed the size of 20 Mb are copied to the ErrorBigScan directory without
being processed into the database. If this occurs, an event is logged to the Windows Application event log.
Inventory Scanner Updates

The Inventory Scanner (LDISCN32.EXE) sports the following enhancements in version 2016:
 Windows 10 support: Devices with a Windows 10 operating system can be scanned for hardware and
software.
 All User Hives of Registry support: The scanner reports Printers, Add/Remove Programs and Custom
Registry Data from ALL user hives of the registry.
 Certificate Hashes: The scanner obtains the public certificate the managed device uses for
communication with the Core Server. The information can be viewed in the device’s inventory in LANDESK
Management > Trusted Certificates. The reported attributes include:
o Computer: Name of the core server
o Created: Certificate creation date and time
o Hash: Name of the hash file
o Hash Function: Hash method (e.g. SHA256)
o Key: Key name
o Organization: Name of the organization
 Dell Express Code Fixed: The scanner reports the correct Dell Express Code.
 Network ID: The scanner reports for the Network ID attribute the Network ID number and the bits in the
subnet mask (e.g. 192.168.114.0/24). The attribute is stored in Network > TCPIP > Bound Adapter >
Network ID.
 IPv6 Address: The scanner reports the IPv6 Address. The attribute is stored in Network > TCPIP >
Bound Adapter > IPv6 Address.
 Application Crash Data: The scanner obtains Application Crash Data as recorded in the event log where
the source equals “Application Error”. The scanner places the data in Diagnostic Data – Application
Errors.

 Boot Degradation Data: The scanner obtains boot degradation information from the Application and
Services logs for event logs un “Microsoft-Windows-Diagnostics-Performance/Operational” events from
Event ID 100 through 111. The scanner places the data in Diagnostic Data - Boot Degradation.
 System Crash Data: The scanner obtains system crash data by counting the number of minidump files in
the folder designated by the registry setting:
HKLM\System\CurrentControlSet\Control\CrashControl\Minidumpdir
The scanner places the data in Diagnostic Data – System Failures.
 If DeviceID Changes BrokerConfig is Automatically launched: If the scanner detects there is a new
DeviceID, the scanner with launch BrokerConfig automatically to get a new certificate for the Cloud
Services Appliance, so it can work whether connected via the Intranet or the Internet. (This requires
LCLXCLNT.DLL to be added to your stand-alone scanner list.)
 Command Line to force Mode=All: The command line switch /SWSCANMODEALL will have the scanner
use Mode=All for the software portion of the scan.
 Logon/Lock: The scanner obtains logon/lock event dates as a part of the scan. The attribute data is found
in the device’s inventory in OS.

If you do NOT want this information, select the Do Not Send Logon/Lock Event Dates checkbox on the
Scanner settings page of the Inventory settings Agent setting.
 LDAP User: The scanner captures Light-weight Directory Access Protocol (LDAP) information and stores it
in the device’s LDAP User > Primary Owner inventory. It also captures the Email information, if it exists. It
leverages the event log logon event, populating the user information from the logon.

 Runtime information for Modern Applications: The scanner captures Application Usage information for
modern applications which run on Windows 8.1 OS and later devices.
 Usage: added a participate in customer experience program

Inventory Scanning Process
The Inventory Scanning Process is as follows:
1. The Managed Device launches the inventory scanner (LDISCN32.EXE).

2. The communication between the Managed Device and the Core Server is initiated via the Web Service
using https port 443 or TCP Port 5007, depending on the setting.
3. The inventory scanner, on the Managed Device, verifies communication with the LANDESK Inventory
Server service (LDINV32.EXE), on the Core Server. (If the service is not running, the scan immediately
quits.)
4. The inventory scanner verifies the LDAPPL3.ldz file on the Managed Device is the same as the file on
the Core Server. (If the file is not the same, the file from the Core Server is copied to the Managed
Device, overwriting the previous file.)
5. The inventory scan runs and writes output to memory.
6. The scan in memory compares to the previous full scan (INVDELTA.DAT file located on the Managed
Device in the C:\Program Files\LANDesk\LDClient\data directory) and the differences are written to a
local file named INVDELTA.TMP, and CHANGESLOG.XML which are incorporated into an updated
INVDELTA.DAT which is forwarded to the Core Server. If this is the first scan, there is nothing to
compare, so the entire scan is sent to the Core Server.
7. The Core Server receives the inventory scan of the Managed Device and writes the data to a .scn file in
the LDSCAN folder, located on the Core Server in the LDMain share.

8. The multi-threaded LANDESK Inventory Server service processes the scan file and inserts the new
data into the Core Database.
Delta Scan Features

Management Suite uses delta scan technology for bandwidth sensitivity reasons. A full scan of hardware and
software ranges anywhere from 400 Kb in size to 4 Mb in size, depending on the amount of software loaded on
the device being scanned. A delta scan is usually 10 Kb to 75 Kb, so the amount of data being sent on the
network is greatly reduced.
How the Delta Scan Works

The first scan will be a complete scan of hardware and software. A copy of that scan is written locally to the
INVDELTA.DAT file in the C:\Program Files\LANDesk\LDClient\Data directory. Each subsequent scan will
scan to memory, and compare changes between the current scan and the previous scan (based on the
contents of the INVDELTA.DAT file). The changes (delta) are compiled into a file (DELTASCAN.ldz) and sent
to the Core Server. The INVDELTA.dat file is then updated to reflect to result of the latest scan for comparison
to the next scan.
Delta Scanning Synchronization

It is possible for a managed device to send a scan, which is not processed. (For example, the Core Server
could go down after the delta scan was sent, or the scan could be rejected because it contains an error.) The
result would be that the scan would be out of synchronization. In order to make certain the scans are not out of
sync, technology is built-in to detect if such is the case, and if so, get back into sync.
The steps to check synchronization of the inventory with the delta scan file are as follows:
1. The Inventory Scanner (LDISCN32.exe) sends the managed device’s Device ID to the Inventory Server
service (LDINV32.exe).
2. The Inventory Server service examines an entry in the database known as a “Sync List” to see if the
Device ID is listed. If so, a “Sync” scan (including hardware, software, non-delta) will be run on the
managed device.
3. The LANDESK Inventory Server service compares the “Last Hardware Scan Date” in the database with
the “Last Sync Date” from the delta scan. (The “Last Sync Date” contains the previous scan date and
time.) If the two entries coincide, they are not out of sync. If they differ, they are out of sync.
4. If the two entries differ, the scan will not be processed. Instead, it will be sent the ErrorScan folder, and
the Device ID is written to the Sync List so that a Sync scan will be run next time.
Device ID
When the first Inventory Scan is run on a managed device, a Device ID is created. The Device ID is used as a
unique identifier in the Core Database. Each entry in the database has a unique identifier. (The reason the
Device Name, or MAC Address, or other identifier is not used, is there is a possibility of a legitimate change in
these identifiers over the life of the asset.) The Device ID is generated by a command to the operating system
to generate a Global Unique Identifier (GUID). This becomes the Device ID and it is written to the registry in
two places.
On a 32-bit Windows Operating System, the places where the Device ID is stored are:
 HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\Common Api
 HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\Common Api

On a 64-bit Windows Operating System, the places where the Device ID is stored are:
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LANDesk\Common Api
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\LANDesk\Common Api
Inventory Scan Types

There are four different Inventory Scan types:
 Full scan: The initial scan that is run on a managed device is a full scan. This scan includes a
complete listing of hardware and software (on all local drives). A local copy of this scan is stored in the
INVDELTA.dat file in the C:\Program Files\LANDesk\LDClient\data folder.
 Delta scan: After the initial full scan is run on the managed device, the scan runs and writes to memory
and compares the data with the INVDELTA.dat file. The changes (delta) between the two inventories
are written to the DELTASCAN.ldz file and sent to the Core Server. For more information, please refer
to the Delta Scan Features section.
 Sync scan: The Sync scan is a full scan of hardware and software (on all local drives). This scan is
NOT sent using the delta scan method. Instead, the complete contents of this scan are sent to the
Core Server and the INVDELTA.dat file is overwritten (in order to have the latest content for
comparison with the next scan).
 Mini scan: A device that has been discovered, but that has not yet been configured with the
Management Suite Agent provides a mini scan. The basic information obtained by the discovery
includes the GUID, MAC address, IP Address, and other minimal information. When a managed
device’s IP Address changes, a mini scan is sent ten (10) minutes later, so the Core Database has the
correct IP address of the managed node. Beginning with Service Pack 1, mini scans can be sent
through a device using a Cloud Services Appliance to connect with the Core Server. Also new in
Service Pack 1 is the change in suffix of a mini scan from .IMS to .MINISCN.
Inventory Scanner Switches

The inventory scanner (LDISCN32.exe) has various switches. (These switches are not case sensitive.) Here
are many of those switches:
Switch Description
/D Directory (Scan starting in this folder)
/F Force software scan (delta scan)
/F- Do not send software
/L- Do not send to Core Server
/MINI Do a mini-scan only
/NOCD Do not send custom data
/NOUI No user interface

/O= [path]filename (Scan to this file)
/Sync This option runs a scan of software and hardware, and sends the complete scan
to the Core Server.
/T [path]filename (Scan to this file)
/V View progress
/W= Seconds (Number of seconds to delay scanning)
/Hash The scanner will obtain the MD5 hash, SHA1 hash, and SHA256 hash for the
software files discovered during the scan. The hashes are included with the scan
information sent to the inventory database.
/S This option designates the server where the LANDESK Inventory Server service
(which receives the scan from the managed device) is running. If the service is
not loaded on this server, the scan terminates. (/S=ServerName)
/SwScanModeAll Force exhaustive file scan. (This option has been in the product for some time,
/hash but the switch was added in version 2016.)
/I=[path] This option designates the source for the LDAPPL3 files. (These files provide the
software library and additional settings the inventory scanner will use.) The
default setting is to use the Core Server as the source.
(/I=http://CoreServer/ldlogon/ldappl3.ldz)
/MUNI This option creates a Unicode MIF file of the scan.
/N This option specifies to not search in subdirectories for software (Used with /D).
/Z=# This option sets how many times the scanner tries to resend the scan if the scan
ends prematurely.
Running the Inventory Scanner

The inventory scanner can be initiated in a number of ways, including being launched from the managed node
as well as from the Console. The following methods are available to launch the inventory scan:
 When the Agent is installed: The Management Suite Agent installs and the Full scan is launched
immediately, by default. (This is set in the Agent Configuration.)
 From the Local Scheduler: This scan is initiated on the managed device. It was set into place when
the Agent was installed. The default is to run an inventory scan once every day. (This can be modified;
it is set in the Agent Configuration.) This is a silent scan; the end-user does not see this scan run.
 Mini scan: This scan is launched from the managed device. It is set to trigger 10 minutes after the IP
Address on a managed device changes. (For example, leaving a docking station at a desk to go to
meeting where wireless is available.) This is a silent scan; the end-user does not see this scan run.

 In the LANDESK Management Group: This scan is launched from the managed device. When the
Agent was installed, a shortcut was placed to launch this scan. It is in the Start > All Programs >
LANDESK Management program group. This scan is visible to the end-user on the managed node.
 From the Manage Scripts tool: This scan is scheduled from the Console. In the Manage Scripts tool
you can see the inventoryscanner script which can be scheduled and started from a Console. (You
can modify or create other scripts to have different options, like /F or /Sync.) All scripts available in this
tool are .ini files in the LDMain\Scripts directory. This option is ideal for scheduling an inventory scan
on a group of PCs at once.
 From a Right-Click > Inventory Scan in a Console: This scan is initiated from the Console. Select
the managed device you want to scan, right-click, click Inventory Scan, and choose the type of
inventory scan you would like: Hardware Scan Only, Hardware and Software Scan, or Full Sync Scan.
There is a hands-on exercise for launching an inventory scan.
Inventory settings in Agent Settings

There are various settings for the inventory scanner in the Agent Configuration.
 On the Start page of Agent Configuration: Is the checkbox option to include software in inventory
scan during installation. One of the final steps of the installation of the Management Suite Agent is an
inventory scan. Selecting this option will include software as a part of the initial scan, while not selecting
the option will result in a hardware only initial scan. The purpose of the initial scan is to add the device
to the Management Suite Console, making management of the device possible.

 In the Agent Configuration > Standard LANDESK agent > Inventory settings: This allows selection
of any of the configured Inventory Settings, as well as access to configure a new Inventory Setting or
edit an existing one.
Inventory Settings:
Inventory settings configurations set actions that will take place when the Inventory scanner (LDINV32.exe)
runs. These settings are accessed by either clicking the [Configure] button on the Inventory settings page
of the Agent Configuration, or by creating a new Inventory settings configuration in the Agent settings tool.
The inventory settings configure the following actions:
o General settings: The page offers the following settings:

 Name: Set the name of the inventory setting.
 Enable scheduled task history maintenance: Here you select the checkbox if you want to keep
a scheduled task history in the client database. If enabled, set the number of days to keep the
scheduled task history.
 Run inventory scanner automatically after software package installation: Here you select the
checkbox if you want to update inventory data after software packages are installed, rather than
waiting for the next scan interval. You can configure a set number of minutes to delay the scan
(after the software has been installed) as well as add an additional random delay to stagger scans
from other devices.
 Set as default: Here you select if this inventory setting will be the default to be placed when new
agents are deployed.
o Location reporting: This page offers the following settings:

Here you select whether to enable location reporting, and if enabled, to configure the collection intervals.
This is what allows a Windows 8 device (with .NET 4.0) to use location reporting. Location reporting
requires the Let apps use my location to be enabled in the Windows 8 privacy settings.
The default data collection interval is four hours. If the device is marked lost (on the device’s inspector
dialog, Hewlett-Packard page, the When lost collection interval activates, providing more frequent
updates.

o Scanner settings: This page offers the following Inventory scanner settings:
 Send All Executed Files: Select whether or not to include all executed files (kept track in the
registry of the managed device) as a part of the inventory scan. (The default is to enable this
setting.)
 Send File Usage Data: Select whether or not to include file usage data (kept track in the registry
of the managed device) as a part of the inventory scan. (The default is to enable this setting.)
 Force Exhaustive File Scan (NOT Recommended): Select whether or not to include in the
inventory scan ALL file extensions. This results in lengthy scans, very large inventory files, and a
very large Management Suite database. Therefore it is not recommended. (The default is to not
enable this setting.)
 Auto-update LDAppl File: Select whether or not to have files run on managed devices added to
the Master Software List on the Core Server, if the files are not currently there. Items added
through enabling this feature can be seen in the Files > To be scanned section of the Manage
Software List tool. The use case of this feature is to find software which has been installed onto
managed devices but not yet executed, when just one device somewhere in the enterprise has
installed and run the software (and reports because of selecting the Send All Executed Files
feature mentioned above, the software will be able to found on each device it the enterprise. Even
if it has NOT be executed. (The default is to enable this setting.)
 Do Not Send Logon/Lock Event Dates: Select whether or not to report as a part of the inventory
scan the Operating System logon/lock event data. Some have privacy concerns and do not want
this data stored. (The default is to not enable this setting.)

 Post To Web Service: Selects whether or not to send inventory scan information to the Core
Server using the web service on port 443 (if selected) or via TCP port 5007 (if unselected).
 Change History Storage (days): When the inventory scanner runs it creates a file containing
changes since the last scan stored as:
Program Files (x86)\LANDesk\LDClient\Data\ invdelta.dat.
The scanner sends this delta file as a scan to the Core Server. The inventory scanner also uses
the InvDelta.dat file to create a change log on each managed device. The changes log is saved in
XML format on each managed device in the LDClient\Data\changeslog.xml file. The Change
History Storage (days) sets how long history is stored in the changeslog.xml file on the managed
device. (The default setting is 90 days.)
 Software Scan Fequency (days): Sets how often to send software as a part of the Inventory
Scan. (The default is one day.) So that each day one inventory scan includes hardware and
software, while each subsequent scan will be hardware only, unless software was installed and
the Run inventory scanner automatically after software package installation has been selected.
 Data File Extensions: Select whether to have other file extensions other than executable files
and those in the Inherited extensions field included as part of an inventory scan. Include the
period and the file extension to add other file types to the software scan. Separate each file
extension type with a space.
 Inherited extensions: Shows the global file extensions set in the Manage Software List tool in
Settings > DataFileExtensions.

o Software Usage Monitoring: Here you select software monitor settings, including:
 Use software monitor: Select whether or not to have the LANDESK(R) Software Monitoring
Service (Softmon.exe) run on the managed device to gather data on executable files run, and the
accompanying usage data, store it in the local registry, and include that information as a part of
the inventory scan.
 Record software usage statistics to a network location: Select whether to have Softmon.exe
store executable and usage information to a network share rather than to the registry. This is to
capture usage information on non-persistent Virtual Desktop Infrastructure (VDI) devices, since
starting VDI devices wipes any previous registry data.
 UNC path where software monitor data files will be stored: Set the UNC location
 Domain and user name: Enter the Domain\User with write rights to the UNC location.
 Password: Enter the password for the user in the Domain and user name field above.
 Confirm Password: Enter the password again, to confirm, for the user in the Domain and
user name field above.

o Schedule: Set in the Local Scheduler added as a part of the Management Suite Agent when to have
the inventory scan occur on each managed device with this inventory setting.
 When user logs in: Select whether to have the inventory scan occur each time a user logs in to
the managed device. The Max random delay field sets the maximum time to wait before sending
the scan, for randomization purposes. (The default does not select this setting.)
 When IP address changes: Select whether to have the Inventory Miniscan (Miniscan.exe) run
when the IP Address Filter is tripped. The miniscan will capture IP Address information to update
the Management Suite database. Miniscans are process into the database before other scans so
the database is corrected shortly after the IP Address Filter has been tripped. (The default selects
this setting.)
 Use recurring schedule: Select whether to have the Inventory Scan regularly run on the
managed device. This is to periodically get a scan from every managed device in the enterprise, to
keep the Inventory Database accurate. (The default selects this setting of once each day, with up
to a 1 hour delay.)
Inventory Settings in the Local Scheduler

When the Management Suite Agent is installed inventory scans are set to run periodically. These settings are
able to be seen in the Console and on the managed node.
To see the local scheduler settings in the Console:

1. Open the Console.
2. Right-click on the device in All devices and click Inventory OR, double-click on the device in All
devices) – this opens the Inventory of the managed device.

3. Click the + to the left of LANDESK Management – this opens the LANDESK Management section.
4. Click the + to the left of Local Scheduler – this opens the Local Scheduler section.
5. Click the + to the left of Scheduled Tasks – this opens the Scheduled Tasks section. All the scheduled
tasks are listed. You can click on each and see the settings.
Here is what the daily scheduled inventory scan looks like:
Here is what the scheduled mini scan looks like:
To see the local scheduler settings on the managed device:
1. Open a Command Prompt window. (Click Start > Run and type cmd and hit [Enter].)
2. Go to the C:\Program Files\LANDesk\LDClient directory.
a. Type CD\ and hit [Enter].
b. Type CD Program Files (x86)\LANDesk\LDClient and hit [Enter].
3. Type localsch.exe /tasks |more and hit [Enter].
Here is what the two inventory scheduled tasks look like on the managed device.
Real-Time Inventory and Monitoring

Effective desktop management, of necessity, includes the ability to gather real-time information and statistics
from managed devices. To enable gathering this information from managed devices, the Agent Configuration
settings must include Real-time inventory and Monitoring. To display real-time data and interact with processes

within the Inspector tool, both the baseline and extended components options under real-time inventory and
monitoring must be enabled.
To view the real-time Inventory and Monitoring data on the managed device do
the following:
2. Right-click the managed device in the Network View > All devices.
3. Click to select Real-time inventory and monitoring.
Real-time Inventory and Monitoring includes:

Health Summary
Health Summary is the overall health of a device as defined by set conditions and parameters.
Modules that are included in the health summary and are available to be gathered in real-time inventory and
monitoring include the following:
 CPU: Processors and cache
 Network: Cards and traffic statistics
 Memory: Usage information and memory modules
 Storage: Logical drives, physical drives, removable media, and storage adapters
 Cooling: Fans and temperature sensors
 Power: Power supplies

 Chassis: The device’s chassis; view whether the case is open or closed
 Point-of-Sale: The device’s information captured from Ivanti Data Analytics Point-of-Sale import (if that
has occurred).
System Summary
System Summary gathers real-time information on the following:
 Health: Indicator as classified by set conditions and parameters; normal, warning, critical.
 Type: Type of device
 Manufacturer: Equipment manufacturer of the device
 Model: Device model
 BIOS version: Version of BIOS on the device
 Operating System: Device operating system
 OS version: Version of operating system on the device
 CPU: Processor model, manufacturer, type and speed
 Vulnerability scanner: version of tool for scanning for vulnerabilities (vulScan.exe)
 Remote control: version of remote control tool (issuser.exe)
 Software distribution: version of tool for distributing software (SoftwareInstaller.exe)
 Inventory scanner: version of tool for scanning the managed device and reporting inventory to the
core server (LDISCN32.EXE)
 Last reboot: date and time of last reboot
 CPU usage: Percentage of CPU in use at time of real-time check
 Physical memory used: Amount of RAM on the device and percentage of ram in use
 Virtual memory used: Size of swap file and percentage of file in use
 Drive C: size of the drive and percentage of drive space used
Hardware
Hardware is the configuration of modules and the settings that contribute the health status of the device. The
following modules listed in hardware. They are:
 CPU: Includes the volume, type, size, usage and availability (in GB and as a percentage), warning
threshold, critical threshold
o Processors: Includes the ID, description, vendor, load (as a percentage), current speed, and
maximum speed
o Cache: Includes the ID, type, size, write policy, and error correction
 Storage: Includes a listing of logical drives, physical drives, and removable media
o Logical drives: Includes volume, type, size, usage and availability (in GB and as a percentage),
warning threshold, and critical threshold
o Physical drives: Includes drive, model, size in GB, and interface
o Removable media: Includes information on media by type
o CD drives: Includes drive, hardware, and media
o Floppy drives: Included drive, heads, cylinders, and sectors
o Storage adapters: Includes channel ID, SCSI ID, device, type, size, RAID, and status
 Memory: Includes information of the memory type (e.g.):
o Memory usage: Includes both physical and virtual information on type, total size (in GB and as
a percentage), Used (in MB and as a percentage), Free (in GB and as a percentage), warning
threshold, and critical threshold

o Memory modules: Includes information on slot, socket ID, current speed, current size, and
form factor
 Chassis: Includes if the device’s chassis has been opened
 Input devices: Includes information on input devices associated on the device
o Keyboard: Includes description and layout
o Mouse: Includes manufacturer, connector type, and number of buttons
 Motherboard: Includes information on motherboard connections
o Motherboard: Includes manufacturer, model, max CPU, and serial number
o Expansion slots: Includes slot, description, designation, type, width (16 bit, 32 bit, 64 bit), and
status
o BIOS: Includes manufacturer, date, version, and serial number.
 Cooling: Includes information on:
o Fans: Includes sensor and current value
o Redundancy: Includes name and status
o Temperatures: Includes sensor and current value
 Power: Includes information on:
o Power Supplies: Includes type, description, and status
Logs
Logs allows access to various logs on the managed remote device in real-time. The logs that are able to be
accessed in this tool are:
 Application log
 Security log
 System log
 BIOS log
 Alert log
Software
Software allows access to various items, shown in real-time, including:
 Processes: Lists each process and information including the program name, process ID, CPU time,
memory usage (in KB), virtual size (in KB), handles, and threads
 Services: Lists each service and information including the service name, status type and status
 Packages: Lists software and information including package name, version, and vendor
 Environment: Lists each of set environment variables including the name and value
Other
Other includes real-time information on the following:
 Asset information: includes various pieces of the asset including:
o Contact information: with fields for name, position, phone, location, department, and asset tag
o System information: with information like the service tag, serial number, model, model
number, manufacturer, chassis, order number, manufacture date, system version, and battery
 Network information: includes other network information including:
o Devices: including the vendor, description, type, speed, status, and active (yes or no)
o Statistics: including device description, speed, bytes received, bytes sent, packets received,
packets sent, receive errors, and send errors
o Configuration: including TCP/IP address, subnet mask, default gateway, DHCP server, DHCP
lease obtained date, DHCP lease expires date, DNS servers, and WINS servers

o Connections: includes user, drive, and mount point
Remote session
Remote session allows a remote session (Remote Control – legacy or HTML-based)) to be initiated
Monitoring
Monitoring allows the ability to set up performance counters and can relay real-time data, or, if data is stored,
the ability to recall previously saved counters. This facilitates trending to provide insight to health of a device
over a period of time.
Rulesets
Rulesets displays the alerting ruleset(s) deployed on a device as well as additional information on each specific
attribute contributing to the alert ruleset. Information on the ruleset includes: Alert type, State, Action and if the
alert contributes to health (yes or no).
Power options
Power options allows the ability to reboot, power on, or power off the device.
There is a hands-on exercise for Real-time Inventory and Monitoring.
Automated Software Discovery

The Software listed in the inventory of a managed node comes from the various sources:
 Registered MSI applications in the MSI database on the managed device
 Items found in Add/Remove Programs in control panel (hot fixes are included)
 Applications which have been executed
 Applications with a shortcut
 Executable files found on the local hard disk
The following sections are displayed in the Software Tree view on the Inventory window of each Windows-
based Managed Device:
 Add or Remote Programs: Includes programs listed in the device’s registry (from “Add or Remove
Programs” or “Programs and Features” depending on the Windows OS version) and applications
installed from MSI packages (from the MSI database in the registry).
 Package: Includes executed applications, applications with a shortcut, executables found on the local
hard disk(s) which are listed in the LDAPPL3.INI file.
 Product: Used by Software License Monitoring
By default, due to a setting in the LDAPPL3 files (ScanExtensions=.exe) set by ScanExtensions in the
Manage Software List tool, all executables are automatically found. If the applications have not been launched
on the managed device, the information provided about the executable files include:
 Date Discovered
 Days Since Discovered
 File Date
 File Name
 File Size
 Patch
 Version
 Virtualized Application (0 means no, 1 means yes)

If the application has been run on the managed device, the information provided on the executable file includes
all of the above information plus the following additional information:
 Current User: Displays who the user was the last time the file was run
 Days Since Last Used: Displays the number of days since the file was last executed
 Duration: Displays the total number of seconds the file has been executed
 Last Duration: Displays the number of seconds the file was run the last time it was executed
 Last Started: Displays the date and time the file was last launched
 Name: Displays the executable file name found when it was run
 Times Denied: Displays the number of times the file was denied from being run
 Times Run: Displays the number of times the executable has been launched
 Title: Displays the title of the application which was executed
All of the additional information is found by the SoftMon.exe file when the executable file launched. It writes
this information to the registry, and reports the information in the inventory scans. Once the information is in
the registry, it is reported, unless the Management Suite Administrator designates to not report on it by placing
the filename in the To be excluded section in the Manage Software List tool.
Configuring the Inventory Service

The LANDESK Inventory Server service has many settings that are available to the Management Suite
Administrator. The primary tool used to configure the service is SVCCFG.exe which can be accessed from the
Direct Console (not the Remote Console or Web Console) by clicking Configure > Services.
The database pointers are configured using the General tab, the LANDESK Inventory Server service is
configured using the Inventory tab.
General Tab
The General tab is used to configure the settings for connecting to the database. The settings are reflected in
the registry under: HKLM\SOFTWARE\LANDesk\ManagementSuite\Core\Connections\Local

 Database: Displays the name of the database.
 IsNTLM: Displays whether NTLM Authorization to the database is enabled. (False) means NTLM
Authorization is not enabled. (True) means it is.
 IsOracle: Indicates whether the Database Management System (DBMS) is Oracle or not. (False)
means the DBMS is not Oracle; (True) means Oracle is the DBMS. (This is a legacy setting as Oracle
is no longer supported as of SP1.)
 Password Code: The encrypted password with DBO rights to access the database.
 PWD Scheme: The Scheme used to encrypt the password.
 Rollup: Indicates whether the database is a rollup database or not. (A rollup is a merge of multiple
Core Databases.)
 Server: Displays the corresponding Core Server and Instance for the database.
 User: Displays the username with DBO rights to access the database.
 Web Console server name or address: References the Web Server for Web Console access.

Inventory Tab
The Inventory tab is used to configure the Inventory service for the Core Server and database selected on the
General tab. Access the Inventory tab by clicking Configure > Services and clicking the Inventory tab.

The Inventory tab contains the following options:
 Server name: Displays the name of the Core Server.
 Log statistics: Keeps a log of core database actions and statistics. The events logged by this setting
can be viewed in the Windows Event Viewer’s Application log. This should be used for
troubleshooting purposes only as it can generate significant amounts of detail.
 Encrypted data transport: Enables the inventory scanner to send device inventory data from the
scanned device back to the Core Server as encrypted data through SSL. (Enabling this setting adds
overhead to the Core Server.)
 Scan server at: Specifies the time to the LANDESK Inventory Server service will scan the Core Server.
Managed devices scan periodically through agent settings which end up in the local scheduler. Since
the Core Server may not be configured with agent deployment, this setting assures a daily scan for
accurate inventory.
 Perform maintenance at: Specifies the time to perform standard core database maintenance. This
option removes deleted records and old inventory history, and cleans up the Provisioning History as
configured in the OS Provisioning tool (new in SP1). This does not include standard database
management system maintenance, which should be configured separately in the SQL database tool.
 Days to keep inventory scans: Sets the number of days before the inventory scan record is deleted.
Setting this option to zero, disables this feature so inventory scans are kept indefinitely. If this is

configured with a setting other than zero, the entrees whose inventory scans surpass the number of
days set are deleted when the daily Management Suite maintenance is run.
 Primary owner logins: Sets the number of times the inventory scanner tracks logins to determine the
primary owner of a device. The primary owner is the user who has logged in the most times within this
specified number of logins. The default value is 5 and the minimum and maximum values are 1 and 16,
respectively. If all of the logins are unique, the last user to log in is considered the primary owner. A
device can have only one primary owner associated with it at a time. Primary user login data includes
the user’s fully qualified name in either ADS, NDS, domain name, or local name format (in that order),
as well as the date of the last login. This can be used for querying purposes.
Advanced settings
Selecting this from the Inventory Tab of Configure Services displays the Advanced settings window. You can
change inventory-related advanced settings here. As you click each item, help text appears at the bottom of
the window explaining each option. The default values should be fine for most installations. To change a
setting, click it, change the Value, then click Set. Restart the inventory service when you’re done.
Settings include:
 DB Error Recovery Tries: (Default= 500) This setting determines how many times the inventory
service should restart itself with a 24-hour period if it encounters scan file errors. Once this number is
reached, the inventory service will continue to receive scans, but will stop trying to insert scan files into
the database.
 DB Threads: (Default=1) This setting tells the inventory service to start multiple threads that will each
insert scan files into the database. Threads require memory and processing power. Only increase the
number if your core server is underutilized. Valid numbers range from 1 to 8.
 Degradation Sample (minutes): (Default=15) The number of minutes to store data before testing it
against and adding it to the averages in the database.
 Degradation Threshold (percent): (Default=20) Percent of processing degradation before logging an
event into the Windows Applications event log.
 Delete SW Before Process Full Scan: (Default=0) This setting will delete all the software for a given
device before processing its scan file. This setting will only apply to full scans, not delta scans.
 Disable Encryption: (Default=0) This settings tells the client-side scanner whether or not it should
compress its scan file before sending it to the inventory service. (Default=1) This setting tells the client-
side scanner whether or not it should generate delta scans to send the inventory service. Valid entries
are 1 (true) and 0 (false).
 Discovery Storage: (Default=0) This setting tells the inventory service to put a copy of every scan file it
receives in the ManagementSuite\LDScan\DiscoveryStorage directory. Valid entries are 1 (true) and 0
(false).
 Do Core Server Software Scan: (Default=1) Used to set whether the LANDESK Inventory Server
service will scan for hardware and software, or hardware only.
 Do DB: (Default=1) This setting determines whether or not the inventory service will insert scan files
into the database. Regardless of this setting, the inventory service will continue to receive scan files.
(Default=1) This setting tells the client-side scanner whether or not it should generate delta scans to
send the inventory service. Valid entries are 1 (true) and 0 (false).
 Do Delta: (Default=1) This setting tells the client-side scanner whether or not it should generate delta
scans to send the inventory service. Valid entries are 1 (true) and 0 (false).
 Duplicate MACs Threshold: (Default=5) When this number of devices have the same MAC Address,
that address will be added to the Ignored NICs list and the client will no longer send it as an identifying
address.

 Ignore Connection Reset: (Default=1) This setting tells the inventory service not to write scan files to
the LDMAIN\LDSCAN\ErrorTrans directory if the scan file encountered network problems during
transmission from the client. Valid entries are 1 (true) and 0 (false).
 Ignore Mini Scans: (Default=0) This setting tells the inventory service to ignore all requests from a
client to send an .ims scan file to the inventory service. Valid entries are 1 (true) and 0 (false).
 Intermediate File Extension: (Default=SCN) This setting tells the inventory service’s thread that insert
scan files into the database which file extension to look for in the ManagementSuite\LDScan directory.
 Log Purged Computers: (Default=0) This setting will create an LDMAIN\Log\PurgedComputers.log file
that lists the names of every machine purged from the database during the inventory maintenance
routine based on the “Days to keep inventory scans” setting.
 Max Connect Tries: (Default=3) This setting tells the inventory service the maximum number of times
to try to connect to the database when it starts up. Valid entries are between 1 and 10.
 Max Memory Limit (MB): (Default=1000) This setting sets an upper threshold on the amount of
memory that the inventory service can use. If it exceeds this value, the inventory service will restart.
 Max Scan File Size: (Default=20000000) This tells the inventory service not to process and scan files
over a certain size. Scan files that exceed this limit are moved into the
ManagementSuite\LDScan\ErrorBigScan directory.
 Max Thread Priority: (Default=0) This setting determines whether or not the threads that insert scan
files are given first priority with the operating system. Valid entries are 1 (true) and 0 (false).
 Off-Core Inventory Server: This is the name of the machine on which you have installed an inventory
service in an effort to offload your core serve.
 Query Timeout: (Default=600) This setting refers to the number of seconds to wait before timing out on
the database connection. Valid entries are between 30 and 3600.
 Refresh Rate: Each instance of the inventory service needs to resync its copy of the Force Full Scans
list. This setting specifies the number of minutes the inventory service will wait before checking to see if
a resync is necessary.
 Scan File Prefix: (Default=SCA) This setting tells the inventory service to preappend this string to al
scan file names before writing them to the ManagementSuite\LDScan directory. This string may not
exceed 15 characters.
 Seconds Before Retry: (Default=30) If the inventory service can’t connect to the database and it’s
supposed to try again (Max Connect Tries), this setting determines how many seconds the inventory
service will wait before retrying to establish a database connection.
 Send All Executed Software: (Default=1) This setting informs the inventory service to tell each
scanner to always send software information for files that have been executed on each managed node.
 Send All File Hashes: (Default=0) This setting informs the inventory service to tell each scanner to
send hashes for each file that will be inventoried.
 Send Product Definitions: (Default=1) This setting informs the inventory service to tell each scanner
to detect and report installed software products on each managed node.
 Send Software File Info: (Default=1) When this is set, the inventory scanners will include file
information in a software scan.
 Store Scans: (Default=0) This setting tells the inventory service to put a copy f every scan file it
receives in the ManagementSuite\LDScan\Storage directory. Valid entries are 1 (true) and 0 (false).
 TCP Port: (Default=5007) This is the TCP port on which the inventory service will receive scan files
from a client-side inventory scanner.
 UDP Port: (Default=5007) This is the UDP port on which the inventory service will receive scan files
from a client-side inventory scanner.

 Use Connection Address: (Default=1) This setting tells the inventory service to get the real IP address
of the client, instead of the reported NAT environment. Valid entries are 1 (true) and 0 (false).
 Use Rolling Log: (Default=0) This setting tells the inventory service to generate a log file that will
enable troubleshooting the inventory service. Valid entries are 1 (true) and 0 (false).
Unknown Items
This setting on the Inventory Tab of Configure Services limits the data entered into the database to what is
modeled. This blocks items that come in from inventory scans which are not configured into the schema of the
database, protecting the database from data which could create corruption. Any blocked items are listed, so
the schema can be configured to include them if so desired.
Options can be set to:
 Allow: This will model the data into the schema, so at next scan the data will be added to the database.
 Delete: This will delete the selected item(s) from the list. If another scan tries to add that attribute again, it
will be blocked but will re-appear in the list.
 Ignore: This will set that data to NOT be included or ever listed again for inclusion into the database. Items
set to ignore should be kept to a minimum, as a long list would affect database performance.
Software
This setting on the Inventory Tab of Configure Services displays the Software Scan Settings window.
In this window you can configure:

 The frequency the software is scanned when the inventory scanner runs (by default only once per day
– the first inventory scan of that day).
 How long to save the inventory history.
Inventory History
To configure which attributes are to be entered into the inventory history, go to Configure > Inventory
History.
Choices for Inventory History include:
 Inventory: Logs each attribute change, set in the Inventory History, and can be viewed by clicking View >
Inventory History.
 NT Log: Logs each attribute change to the Application Event log [as Informational (blue), Warning (yellow),
or Critical (red)], as designated in the Log/Alert severity field.
 Alert: Logs each attribute change to the Alert log, and can be viewed by clicking Tools [or Toolbox] >
Reporting / Monitoring > Logs.
o Attributes: Allows the user to select attributes to be included in the scan.

 Manage duplicates: Manages the issue created when imaging, by oversight or mistake, propagates the
same unique identifier to multiple managed nodes (enabled by default).
o Devices: Opens the Duplicate devices window to configure how duplicate devices are handled. Settings
can be made to delete items in the database with the same name, or with the same MAC address, or
both (default.)
o Device IDs: Opens the Duplicate device ID window to select attributes that uniquely identify devices.
This option helps avoid having duplicate device IDs scanned into the core database. The default setting
includes both the device name, and the MAC address of the NIC.
 Status of Inventory Service: Indicates whether the service is started or stopped on the Core Server.
o Start: Starts the LANDESK Inventory Server service on the Core Server.
o Stop: Stops the LANDESK Inventory Server service on the Core Server.
o Restart: Restarts the LANDESK Inventory Server service on the Core Server.
LDAPPL3 files
Management Suite seeks to update the numerous managed nodes only as often as required, and always using
the least amount of bandwidth. Because of this, the LdAppl3.ini file (the operative file that has the software
library, and various settings for the inventory scanner) has an advanced update procedure. There are many
files in the LDLogon share which influence, change, and modify the LdAppl3.ini file.
The LDAPPL3 files in are:
 LdAppl3.bak: An iteration backup of the previous version of the LdAppl3.base file.

 LdAppl3.base: The last synchronized software list.
 LdAppl3.baz: The compressed form of the LdAppl3.base file.
 LdAppl3.ini: The combination of the LdAppl3.base file and the LdAppl3.template file. This is the file
used during the inventory scan.
 LdAppl3.ini.bak: A backup of the previous version of the LdAppl3.ini file.
 LdAppl3.ldz: The compressed form of the LdAppl3.ini file, used to update managed devices.

 LdAppl3.pat: A delta file from the LdAppl3.base file. The changes to LdAppl3 since the Management
Suite Administrator last forced update are stored here.
 LdAppl3.paz: The compressed from of the LdAppl3.pat file.
 LdAppl3.template: The template file for the LdAppl3.ini file. Changes made to the default settings of
the LdAppl3.ini file should be made in the Manage Software List tool. This file is merged with the
software data in the Core Database to create the LdAppl3.ini when changes are made in the Software
License Monitoring tool. To commit all changes, the Update icon in the Manage Software List tool
should be clicked.
 LdAppl3.template.bak: A backup of the previous version of the LdAppl3.template file.
 LdAppl3.tmp: An iteration file used in modifications and updates of LdAppl3 files.
 LdAppl3.reset: (located in the C:\Program Files (x86)\LANDesk\ManagementSuite) is a zero-byte file
used for date stamping the LdAppl3.ini file.
To assure it has the latest and correct version of the LdAppl3.ini file, the managed device assures it has the
latest version its copy of LdAppl3.ldz file by comparing its copy with the Core Server using a checksum
comparison. If an updated version is needed, the much smaller LdAppl3.ldz file is copied (utilizing less
bandwidth) and then the client expands it to create the full LdAppl3.ini file. Updates are also able to be
communicated using the LdAppl3.paz file. Again, a very small, compressed file, can update the large
LdAppl3.ini file on the managed devices, using very little bandwidth.
When the Make Available to Clients button in the Manage Software List tool is clicked, the
LdAppl3.template file and LdAppl3.base file, and updates in the LdAppl3.pat file, and any other changes
needed, are merged to update the LdAppl3.ini file and a corresponding LdAppl3.ldz file is created.
Since new applications and versions of software are released continually, the Management Suite Administrator
needs the new applications added to the software library. However the LdAppl3.ini file is not edited directly.
Fortunately, when the SOFTMON.exe discovers new software, it adds it to the registry, and when the Make
Available to Clients button in the Manage Software List tool is clicked, it adds it to the Software list, and
associated LdAppl3 files.
If there is a need to modify behavior settings in the LdAppl3.ini file, this should be done by using the Manage
Software List tool, and then clicking the Make Available to Client button on the Manage Software List
toolbar. This commits the changes to the LdAppl3.ini file.
Through all of this technology managed devices only get updates when changes have occurred, and always
use the least amount of bandwidth to update. The compressed forms of files are sent to update the full
LdAppl3.ini on the managed devices.
Non-Persistent Virtual Desktops and SOFTMON.EXE

With the popular use of Virtual Desktop Infrastructure (VDI), SOFTMON.EXE has been enhanced to track and
report software usage on non-persistent virtual desktops. With non-persistent virtual desktops, the virtual
device is assigned (from a pool of resources) when the user logs in. The virtual device pulls the user’s roaming
profile to place any personalized settings. At the end of the session, the virtual device is reverted to its original
state. So each time the virtual device is brought up, it is in a snapshot state. All changes made in a prior
session are lost (including registry data SOFTMON.EXE has written).
To address this, SOFTMON.EXE can be set to write software usage data to a network share. When set to do
this (in the Agent configuration in Software Usage Monitoring) SOFTMON.EXE will load every 10 minutes,

write to the registry setting in the network file (or create a new one if it does not yet exist) the software usage
data. This data is then reported up to the database when the inventory scanner runs.
To enable this feature go to the Inventory settings in Agent settings. Click on the Software Usage
Monitoring page. Select the Record Software usage statistics to a network location checkbox.
Manage Software List

Through this tool, you can add Registry Items and WMI Items to the Custom Data section of the inventory. You
can also select and add additional software you want captured into inventory. You can designate to Monitor
URL items, and make other setting changes.

There is a hands-on exercise to View Software information in Inventory.
Capture Registry Information and add it to Inventory

To capture Registry Information from managed devices and add that data to the Inventory scans, add items to
the Registry Items list. The steps to do this are as follows:
1. In the Management Suite Console, click Tools > Reporting / Monitoring > Manage software list. (The
Manage Software List tool opens in the bottom pane of the Console.)
2. Expand Inventory > Custom Data > Registry Items.
3. Right-click Registry Items and Click Add. (The Registry Scan Item Properties window appears.
4. Fill out the fields

a. Root Key: Select the registry root key on the managed device holding the value.
b. Key: Select the registry key holding the value you wish to capture.
c. Value: Select the value you wish to capture.
d. Attribute Name: Type the attribute name as you wish it to appear in the database in the Custom Data
section.
5. Click [OK].
6. Click the Make Available to Clients icon.
Some Custom registry keys are already designated by default.

There is a hands-on exercise for capturing registry information in the inventory scan.
Capture Custom WMI Data and add it to Inventory

Management Suite Inventory already gathers some Windows Management Instrumentation (WMI) data. A
Console user can add additional custom WMI data to be captured in the inventory scan, which is subsequently
added to inventory data in the database. To add additional data, it must be modeled in the database. The data
will be stored in the CustomData table.
To add WMI items to the inventory scan, select the WMI class, instance, and the namespace which contains
the class. (This is somewhat analogous database usage of an instance, tables, and attributes.) To discover
what these items are for a WMI class, use a tool like Microsoft CIM Studio (or Powershell in Windows 7) to
browse the WMI classes.
One example is:

 NameSpace: root\dmv2
 Class Name: Win32_Printer
 Property: Name, Network, ServerName
To add WMI items to the inventory scan, do the following:

2. In the Manage Software List pane, click to expand Custom Data. (Registry Items and WMI Items are
shown under Custom Data.)
3. Right-click WMI Items and click Add. (The WMI Scan Item Properties window appears.)
4. Fill in the fields articulating the registry items you want to capture.
a. Enter root\CIMV2 in the NameSpace field.
b. Enter Win32_Printer in the Class Name field.
c. Enter Printer in the Display Object field.
d. Click [Add]. (The Edit Property portion of the window becomes active.)
e. Enter Name in the Property Name field.
f. Enter Printer Name in the Display Name field.
g. Click [Apply]. (The additional items now appear in the Properties portion of the window.)
h. Click [Add]. (The Edit Property portion of the window becomes active.)

i. Enter Network in the Property Name field.
j. Enter Network in the Display Name field.
k. Click [Apply]. (The additional items now appear in the Properties portion of the window.)
l. Click [Add]. (The Edit Property portion of the window becomes active.)
m. Enter ServerName in the Property Name field.
n. Enter Server Name in the Display Name field.
o. Click [Apply]. (The additional items now appear in the Properties portion of the window.)
p. Click [OK]. (A message appears asking if you want to apply Property changes.)
q. Click [Yes]. (The addition to the WMI Items appears in the right pane.)
5. Run an inventory scan on the managed device to now have the additional WMI Items in the database.
Adding Software to be Scanned

To add software to be scanned:
2. Expand Inventory > Files > To be scanned.
3. Right-click To be scanned and click New File. (The File Properties window appears.)
4. Type the Filename, to add an entry to find all sizes and versions of the file on managed devices.
OR
Click the [+] to expand to designate the file size and other optional fields to find the files of a specific name
and size on the managed devices.

5. Click [OK] to add the file.
6. Click the Make Available to Clients icon.
When the Manage Software List opens, none of the entries in the sections show up. In order to search for an
application, use the find tool. The tool is populated with items found via inventory scans of managed devices.
The sections in the Files portion of the Manage Software List are as follows:
 To be scanned: Designates the software that if found on a managed device’s local drive will be
reported in its inventory in the Package section under Software.
 To be dispositioned: Contains files that have been discovered on devices, but are not designated to
be scanned for. Any applications in this list that you want to scan for need to be moved to the To be
scanned group.
 To be excluded: Lists applications to ignore during the software portion of the inventory scan.
Monitoring URL Items

Additional functionality introduced in version 9.5 is the ability to track web page use by URL. The reason for
this function is ability to track Web-based applications and software as a service (SaaS). This data (stored in
the FileInfo table) is accessible to Software License Monitoring. This is done in a passive way and is in no way
intended as a web policy enforcement tool. The Monitored URL items track web page visits and store the
Domain information.
You can enter a domain name with subdomains (up to 10 levels of subdomains, with no more than 60
characters per level) separated by dots. You cannot include specific paths. Also, the domain name cannot
include invalid characters (which will be met with an error message for correction).
To Add Monitored URL Items, do the following:

2. In the Manage Software List pane, right-click Monitored URL Items.

3. Click [Add]. (The Monitored URL Properties window appears.)
4. Type salesforce.com in the URL field.
5. Click [OK]. (The Monitored URL Items list in the right pane now includes the addition.)
Settings
The settings portion of the Manage Software List displays and allows adding additional settings. To add to
these settings, right-click the attribute and click [Properties], then use the [New], [Edit], and [Delete] buttons,
and click [OK]. Remember to click the Make Available to Clients after adding to these settings. Prior to
version 2016 these settings were a part of the LDAPPL3 files, but now these settings are in the database.
 CfgFiles: Lists .cfg files to be saved from managed devices into the database. (This feature was added in
SP1.)
 DataFileExtensions: Lists file extension types to be included in the inventory scans from managed
Windows devices (.PST files, for example). This information can be found under the Software.Data Files
database attribute and will include the file name, path, file date, and file size.
 Exclude Folders: Lists folders whose software will be excluded from the inventory scan from Windows
devices. The following folders are already excluded by default:
- \recycled and \recycler
- %USERPROFILE%\LOCAL SETTINGS
 \TEMP and \TEMPORARY INTERNET FILES
- %USERPROFILE%\Application Data\Thinstall
- %windir%
 \$ntservicepackuninstall$, \installer, \lastgood*, \driver cache, \registeredpackages, \temp,
\system32\dllcache, \$NtUninstall*, ServicePackFiles\i386, and \i386
- \$LDCFG$
- \SYSTEM VOLUME INFORMATION
- \SP3
- \SP4
- \Library
- \DOCUMENTS AND SETTINGS\LOCALSERVICE\LOCAL SETTINGS
 \TEMP and \TEMPORARY INTERNET FILES
- %ProgramFiles%
 \LANDesk\LDClient
o \bkupcfg, \cache, \data, and \sdmcache
 \LANDESK\SHARED FILES, and \COMMON FILES\MICROSOFT SHARED
- \LDClient
 Temp, and SDMCACHE
 Ignored MACs: Lists MAC addresses (up to 40 can be listed) which the scanner should NOT consider
acceptable when choosing an address to be used for identification. (This is the address assigned to
Network – NIC Addess and is used on the Core Server to identify duplicate device ID’s.) The use case is
the exclude addresses issued for a Virtual Private Network (VPN) environment, where multiple devices
could have the same MAC address depending on when they last connected via the VPN (and ran an
inventory scan during that time).
 MacMultimediaExtensions: Lists the file extension types that add to the Multimedia Files section of the
inventory scan, from Macintosh Apple OS X managed devices. Extensions are case-sensitive, so care

must be taken to add items using the correct case. The Multimedia Files section in the managed device’s
inventory shows:
o Number of Files: Displays the total number of files on the local drives that have the multimedia
extension listed.
o Scanned Extensions: Displays the extensions counted as multimedia files
o Total Size: Displays the sum total size of all multimedia files on the local drives.
 MacScanExtensions: Lists the file extension types to be included in the inventory scans from managed
Macintosh devices.
 MacSearchFolders: Lists additional folders to include in the inventory scans from managed Macintosh
devices. The scanner searches the /Library, /Applications, /System, and /User folders by default. (The
files included in the inventory scan from the default folders and those listed in the MacSearchFolders
section are those whose extensions are listed in the MacScanExtensions section.
 MIFPath: Lists the directories in which the inventory scanner will look to find Management Information Files
(MIFS). The default includes C:\DMI\DOS\MIFS.
 MultimediaExtensions: Lists the file extension types that add to the Multimedia Files section of the
inventory scan, from Windows devices. The Multimedia Files section in the managed device’s inventory
shows:
o Number of Files: Displays the total number of files on the local drives that have the multimedia
extension listed.
o Scanned Extensions: Displays the extensions counted as multimedia files
o Total Size: Displays the sum total size of all multimedia files on the local drives.
 ScanExtensions: Lists the extensions that will be searched for software reporting. If the extension is not
listed, the application will not be listed in the software portion of the inventory scan.
 SMBIOS Ignore: Lists strings that you want the inventory scanner to ignore from the SMBIOS scanner. By
default, already ignored strings include: Unknown, N/A, Not Available, and None.
 Usage Files: If this list is left blank usage data will be sent for all monitored products. However, if you add
files to this list, only usage data for listed files will be included in the inventory scans from managed
devices.
There are hands-on exercises for using these pieces in inventory.
Custom Data Forms

There are times when it is preferable to add additional informational items to associate with the inventory of a
managed device. Management Suite enables you to do this with the Custom Data Forms tool. You can query
and report on data added to inventory with this tool.
The Custom Data Forms tool enables you to create forms with the Form Creator. The created forms are then
copied onto the managed devices (into the C:\Program Files\LANDesk\LDClient directory). Once forms are
present on a managed device, the Form Viewer launches the form, and data is entered, the data is saved into
the LDCustom.dat file in the LDClient directory, and reported in all subsequent inventory scans from then on.
Sending Forms to Managed Devices

The forms can be sent to the managed devices in different ways:
1. The forms can be scheduled in the Scheduled Tasks tool.
2. The forms can be set to copy onto managed devices when the Agent is deployed. (This is done in Agent
configuration > Custom data forms > Forms sent with agent.)

Launching Forms
The form can be pulled up in an automatic way, or launch manually on the managed node. The settings for this
are in the Agent Configuration.
 Manual update forms: A scheduled task must be created to deploy new or updated forms to managed
devices. (There will be no automatic update.)
 Automatic update: Ensures that each time the managed device starts up, or runs an inventory scan
(whichever setting is chosen in Display forms to end user) if there is a new or updated form, the Form
Viewer will launch.
 Display forms to end user: Works in conjunction with Automatic update.
o On startup: When the managed device starts up, it checks to see if there is a new or updated
form, and if so, the Form Viewer will launch.
o When inventory scanner runs: When the inventory scanner runs on the managed device, it
checks to see if there is a new or updated form, and if so, the Form Viewer will launch.
o When launched from the LANDESK program folder: Launches the Form Viewer on the
managed device. (This manual process can be launched any time.)
If a form is newly copied to a managed device, when the Form Viewer is launched the data fields are empty
(because there is no corresponding LDCUSTOM.dat file). If an updated form is launched, the fields that existed
in the previous forms will contain the previous data (populated from the LDCUSTOM.dat file) and the fields can
be overwritten, or left with the existing data. New fields will be empty. When the modifications are completed,
the LDCUSTOM.dat file will contain the new data. The date and time of last modification to the
LDCUSTOM.dat file are included in the data.
When the Custom Data Form data is placed into the database, it can be viewed in the managed device’s
inventory in LANDESK Management > Custom Data Forms > Form Name.

Process
Here is the delivery process for Custom Data Forms:
1. When the Agent is deployed to the managed device, the frequency of when the Forms Viewer will be run
(scan, start up, etc.) is set. This information is saved in the LDCUSTOM.ini file.
2. A form is created and deployed.
3. The Form Viewer runs, the form is presented.
4. The data is written to the LDCUSTOM.dat file.
5. The inventory scanner picks up the data, and writes it to the inventory scan.
6. The inventory scan is processed into the database.
The files which run Custom Data Forms are as follows:
 LDCCFG.OCX: User interface to create the form in the Direct and Remote Consoles.
 Form_list.asp: Form management window in the Web Console.
 Form_edit.asp: Form edit window in the Web Console.
 LDCSTM16 & 32.exe: User interface to present the form on the managed device.
 LDCSTM16 & 32.dll: Used by the inventory scanner and the LDCSTMxx.exe file.
 LDCSTMHelp.ini: Contains the information on when the form should run.
 LDCUSTOM.ini or LDCUSTOM.frm: Contains the form information, e.g., question(s), drop-down
options, etc.
 LDCUSTOM.dat: Stores the data from the form. The inventory scanner captures the data from here, to
send it to populate the database.
There is a hands-on exercise for using Custom Data Forms.
Resources for Inventory

For complete information regarding Inventory, there are many points covered on the Community Website
Inventory Landing Page: http://community.ivanti.com/support/docs/DOC-23849.
Inventory on MAC devices

Best Known Method for troubleshooting inventory on the Mac Agent in 9.5 can be found at:
Queries
Queries can be helpful in managing IT assets. Searches for can be created to include any criteria held in the
database (whether it be hardware information, user information, or software information).
Queries can be organized into groups in the Network View. New queries and new query groups can be created
by clicking to expand Queries, right-clicking the My queries or Public queries group, and clicking New query
or New group.
 My queries: Lists queries that have been created by the currently logged-in user, and queries that a
Management Suite administrator has added to the user’s group. A user can create, modify, and
delete query groups and queries under their My queries group. They can also copy queries to this
group from the Public queries group.
 Public queries: Lists queries that a Management Suite administrator, or users who have been
granted the Public query management (PQM) Edit public right. Users with the Management Suite
administrator right and users with the PQM Edit public right can add, modify, or delete query groups or

queries in the Public Queries group. All Console users can see and copy queries in this group to their
My queries group.
 All queries: Lists all queries that can be seen by the currently logged-in user. All queries is a
composite of the user’s My queries and Public queries groups.
Query Operators
The dialog box to create a new query has the following functions:
Figure: Create a Query
 Name: Sets the name of the query as it will be listed in the query groups.
 Machine Components: Lists inventory components and attributes the query can search.
 Relational (Boolean) Operators: Lists the operators which determine values for which the query can
satisfy. They are as follows:
o =: Equals
o <>: Does Not Equal
o <=: Less Than OR Equal to
o >=: Greater Than OR Equal to
o <: Less Than

o >: Greater Than
o Exists: Has a Non-Null Entry
o Not Exists: Has a Null Entry
o Like: Contains
o Not Like: Does Not Contain
 Display Scanned Values: Lists a unique list of values for the chosen inventory attribute. You can
select from the list OR manually enter an appropriate value in the Edit values field. (If the selected
relational operator is Exists or Does Not Exist, no values are displayed.
 Logical Operator: Determines how query criteria logically relate with each other.
o And: Both the previous query statement and the statement to be inserted must be true to satisfy
the query.
o Or: Either the previous query statement or the statement to be inserted must be true to satisfy
the query.
 Insert: Inserts a new statement into the criteria list and logically relates it to other statements according
to the listed logical operator.
 Edit: Lets you edit the selected query statement. When you finish making edit changes, click the
Update button.
 Multi-Insert: Provides ability to insert multiple values using a copy and paste with a delimited list of
values. You can define the delimiter, paste up to 50 values, click the [Parse] button, and the values will
be added. There is a checkbox to select whether to remove leading and training white space.
 Delete: Deletes the selected statement from the criteria list.
 Clear all: Deletes all statements from the criteria list.
 Criteria list: Lists each criterion statement inserted into the query and its logical relationship to the
other listed statements. Grouped statements are surrounded by parentheses.
 Group (): Groups the selected criteria together so they are evaluated together before being evaluated
with other criteria.
 Ungroup: Ungroups the selected grouped statements.
 Filters: Opens the Query Filter dialog box that displays device groups. Selecting one or more of these
limits the input considered in the query to items in the selected groups.
 Select Columns: Lets you choose what attributes appear in the query results. Select an attribute in the
left window, and then click the right-arrow button to add it to the column list. You can manually edit
the Alias and Sort order text, and your changes will appear in the query results list.
 Qualifier: The qualifier button is used to limit the results of one-to-many relationships in the database;
without it, you will get the same machine listed numerous times in your result set. (For example, if you
want to see which version of Microsoft Word is installed on every device in your organization, you
would insert Computer.Software.Package.Name = ‘Microsoft Word’ in the query box and select
Computer.Software.Package.Version in the select columns list. However, simply listing the software
version will list every version of every piece of software installed on each device, which would result in
a huge list which you do not want. To get the information you desire, you need to limit (qualify) the
version to only Microsoft Word. Click the Qualify button to insert Computer.Software.Package.Name
= ‘Microsoft Word’. This will return only the versions of Microsoft Word.
 Browse column sets: This brings up all created column sets for you to select from to apply to the
output columns, eliminating the need to select them all again.
 Save: Saves the current query. When you save a query before running it, the query is stored in the core
database and remains there until you explicitly delete it.

Query statements are executed in the reverse order (e.g. from the bottom up) shown in the criteria list if no
groupings are made. Be sure to group related query items so they are evaluated as a group; otherwise, the
results of your query may be different than you expect.
There are hands-on exercises for creating queries, importing and exporting queries, and importing
devices from a vendor using a .csv file.
Troubleshooting Inventory Issues:

The first, and likely most important, tool in troubleshooting is to know the order of steps the technology takes to
perform a specific task. Then, finding the step that fails can lead you to what needs to occur.
LANDESK Inventory Server service Logging

The LANDESK Inventory server service writes inventory events to the Windows Application event log. Access
the Event Viewer window by clicking Start > Administrative Tools > Event Viewer. Some of the events the
server writes are as follows:
 3: Invalid Scan sent from client.
 9: Inventory server loaded successfully
 11: Database successfully opened.
 2388: Inventory server complete database maintenance.
 2389: Inventory server started database maintenance.
 2391: Inventory data for specified device is out of sync – a full scan will be forced.
 2392: Duplicate Device has been detected.
 4098: Attribute – Computer.last hardware scan, data modified for specified node.
Silent scans, if they fail to connect with the server holding the LANDESK Inventory Server service, will fail and
exit immediately, without notification the scan has failed (after all, it is a silent scan). If the scan is verbose, and
it fails, it will leave a message that it failed and why. Some of the reasons it may fail are as follows:
Symptom Solution
LDISCN32: Failed to resolve The scanner could not contact the Core Server by name. Make sure the
the Host Name command line has the correct Core Server name, resolve Name Resolution
problems on your network, or replace the Core Server name in the
command line with the IP address of the Core Server.
LDISCN32: The inventory Make sure the LANDESK Inventory Server service is running on the Core
server <Core Server name> Server. Make sure the port number (default 5007 decimal for TCPIP) is
did not respond correct on the command line and that the port is open on all routers
between the Management Suite managed device and Core Server. (Check
the values for TCP port and UDP port on the Core Server in Advance
settings on the Inventory tab of Configure > Services).
Complete scans are not Many times this occurs because one or more lines in the scan is wider than
processed into the database, a column of a table allows. Check the Application Event Log (which logs
but are rejected and placed in reasons for all rejected scans) which will list the table and column needing
the ErrorScan folder adjustment.
Inventory scans are building Make sure the DoDB database setting in the Advanced settings on the
up in the LDSCAN folder on Inventory tab of Configure > Services is set to 1. (Setting this value to 0
the Core Server and no scans

are being processed into the will cause scans to be collected on the Core Server and will not allow the
database. scans to be processed in to the database.)
Unable to locate the master The scanner could not find the LDAPPL3.ldz file the path specified. Make
software list at sure the path is correct by the /i switch, and that the user has rights to
\\CoreServerName\LDLOGON\ access the file. (If this is the case the scanner will still run without
problems, because it used the local LDAPPL3.ldz. If there is a different
LDAPPL3.ldz. Your local copy LDAPPL3.ldz file in the path specified, it did not get copied locally as it
may not be current should have.
The files that are under the LDSCAN folder, and what goes into those directories are as follows:
 Decomp: Files are temporarily placed here until decoded and sent to the LDSCAN directory when
Encrypted Data Transport is enabled on the Inventory tab of Configure > Services.
 ErrorBigScan: Scans larger that are 10000000 bytes or larger are sent to this directory and not
processed into the database. To adjust the size change Max Scan File Size in Advanced Settings
accessed on the Inventory tab of Configure > Services.
 ErrorScan: Scan files that are rejected are not processed and are sent to this directory. The reason the
scan file is rejected is written to the Application Log in the Event Viewer. (Duplicate ID was found,
attribute column not set high enough to receive the attribute in the scan, delta scan out of sync, etc.)
 ErrorTrans: Scan files which fail the Cyclical Redundancy Check (CRC) are placed in this directory.

Check for Understanding concerning Inventory
1. How do you enable managed devices to send inventory to the Web Service on the Core Server?
2. What port does the managed device use to send inventory when posting to the Web Service?
3. Where do you configure the Core Server settings for Inventory Service degradation monitoring
(Degradation Sample, and Degradation Threshold)?
4. Where do you set the inventory on managed devices to “Do Not Send Logon/Lock Event Dates” and how
does this impact the inventory scan on the managed device?
5. What is the default Max Scan File Size in Management Suite 2016, and what does the setting do?
6. What new features are in Inventory in Management Suite 2016 concerning Application Crash Data, and
System Crash Data?
7. What are the different ways to launch an inventory scan?
8. What are differences between looking at inventory scans and looking at real-time inventory, and why?
9. What are the LDAPPL3 files, and what do they do?
10. What are custom data forms and how are they used?
11. How are queries created and what are different ways they are invoked?

Inspector
Module Objectives
 Cite business issues the Inspector solves

 Use the Inspector on managed devices
 Use the Inspector on the Core Server
 Add pictures of users in the Inspector
 List how to create Custom Inspectors

Inspector Use Case
A Management Suite Administrator manages a large number of devices. Through Management Suite
implementation, a great number of managed devices have been recipients of:
 numerous Operating System and Application patches
 various software applications
 Remote Control sessions
Now, the Administrator needs to examine individual managed nodes to see:

 who is currently logged into the device (including a picture of the individual)
 which Management Suite Agent configuration is in place
 which processes are currently running (and possibly stop a process)
 which services are running (and possibly stop a process)
 when the last hardware inventory scan was run
 when the last software inventory scan was run
 when the last vulnerability scan was run
The Inspector shows each of these items and more, in a self-contained window. It can provide a look at that
time, or be set to continually update in 60-second, 5-minute, or 10-minute intervals. When Inspector windows
present graphs, they are actionable.
There are also inspectors for:

 queries • scheduled jobs
 software packages • delivery methods
 vulnerability or patch definitions • users and groups
 roles • scopes
 teams • agent behaviors
 column sets • scripts
Utilizing Inspector
The inspector is available for different devices and feature tool sets including:
 Managed Devices
 Core Server
 Queries
 Scheduled Tasks
 Vulnerabilities
When the Inspector is launched it can dynamically be updating or it can be unlinked. In an unlinked state the
data is shown as it was when the Inspector was launch. It can then be set to update every 60 seconds, every 5
minutes, every 10 minutes, or with auto-refresh off.
When the Inspector is opened to reveal information regarding a managed node it populates with pre-set items
based on .XML files.
Inspector for Managed Devices

The Inspector can be set to automatically open an Inspector window when an object is right-click selected. To
invoke this method:

1. Open the Management Suite Console
2. Click View > Auto Inspector.
To manually open the Inspector:
1. Open the Management Suite Console

2. Right-Click the desired item in the console
3. Click Inspect. (The Inspector window for the desired item opens.)
Inspector for Managed Devices - Properties Tab
The Properties tab shows:

The Node state expander includes the currently logged-on user along with a picture of the user.
(The picture can be manually added or imported from LDAP to the
C:\ProgramFiles(x86)\LANDesk\ManagementSuite\images\ Inspector directory.) This expander also indicates if
the screen saver is enabled.
The Actions expander allows starting a Remote Control session or a Ping command to the managed node
with one-click.
The General expander brings information about the managed node. In this particular setting the file
C:\Program Files\LANDesk\ManagementSuite\
inspectorWeb\Inspectors\ComputerQuery.xml defines the controls shown.
Inspector for Managed Devices - Processes Tab
The Processes tab shows processes running on the managed devices. These processes can be stopped
remotely by right-clicking a processes and clicking Kill process.
The LANDESK processes expander includes the running processes which are the Management Suite
processes as defined by the ldprocs.txt file located in the

C:\Program Files\LANDesk\ManagementSuite\inspectorweb\cfg directory.
The processes expander shows all processes shown in task manager on the managed device. Both
expanders show the Program name, Process ID, CPU time, Memory usage, Virtual size, handles, and threads.
Inspector for Managed Devices - Services Tab

The Services tab shows services running on the managed devices. These services can be started, stopped, or
restarted remotely by right-clicking a service processes and clicking Start, stop, or restart.
The Services expander shows all services shown in task manager on the managed device. Both expanders
show the Services name, Name (file name), Startup type (Automatic - Auto, Manual – Demand, or Disabled –
Disabled) and Status (Started or Stopped).
The LANDESK services expander includes the running services which are the Management Suite processes
as defined by the ldprocs.txt file located in the
C:\Program Files\LANDesk\ManagementSuite\inspectorweb\cfg directory.

Inspector for Managed Devices – LD Download Tab
The LD Download expander shows files downloaded to the managed device.
The columns shown in the expander include: File Name (source location), Source (Source, Preferred, or Peer),
File size, Date, and Peer address.
Inspector for Managed Devices - Users Tab

The Users tab shows users created on the managed device.
Inspector for Managed Devices - Tasks Tab

The Tasks tab shows all tasks which have failed, and all tasks which are in the LANDESK Local Scheduler,
and which interface with the core server. (The tasks which are in the Local Scheduler that do not interface with
the Core Server will not be listed.) The tasks in LANDESK Local Scheduler will be listed in expanders by day,
week, and month, (if they exist).
Inspector for Managed Devices - PCI compliance Tab

The PCI compliance tab indicates whether or not the managed device is PCI compliant or not. This is
determined by the “PCI Data Security Standard v1.2” group defined in the Predefined groups of the Patch
and Compliance tool. This requires the vulnerability scan to have been run, and a check for the definitions
defined in the group. If the device is not vulnerable for any items listed in that group, it will be shown as
compliant.
Inspector for the Core Server

To open the Inspector for the Core Server, go the Network View. When the Core Server appears in the right
window, right-click and select Inspect. (If you select the Core Server and Inspect from within All devices, you
get the Inspector of a Managed device rather than the Core Server Inspector. To get the Core Server
Inspector, enter from the top of Network View.)

When the Core Server Inspector launches, the information presented shows data regarding all devices
reporting to that core. The following tabs are presented:
Core Server Inspector - Devices Tab
The Devices tab shows:

The General expander which shows the total number of computers in the database, those added within 24
hours, those added within the last week, and newly discovered devices (in Unmanaged Device Discovery) not
yet dispositioned.
The Devices not scanned in over n days expander shows managed devices which have not sent an
Inventory scan in 7 days, 30 days, 60 days, or 90+ days in a graph.
The Device types added in the last 6 months expander presents in a pie chart the breakdown of device
types including PC, Mobile, MAC, and Server.
Core Server Inspector – Software Licenses
The Software Licenses tab shows:
The License Information expander, which displays the Number of licenses, the last compliance calculation,
the last usage calculation, unused licenses, and unlicensed products.

Core Server Inspector – Distribution
The Distribution tab shows:
The Targeted packages expander, which displays the number of packages modified in the last 24 hours, and
within the last week.
The Tasks expander displays the distribution tasks scheduled to start within the next 24 hours and within the
week.
Core Server Inspector – RBA
The RBA (Role-Based Administration) tab shows:
The LDMS administrators expander shows users who are members of the local LDMS administrators group
on the core server.

The LDMS group administrators expander displays the users who are members of the LANDesk
Administrator role.
Core Server Inspector – Licensing
The Licensing expander shows the number of nodes requiring a Management Suite license.
The Current licenses expander shows the number of licenses purchased from Ivanti (including the version,
quantity, and expiration date of those licenses).

Core Server Inspector – Security
The Security tab shows:
The Anti-virus expander shows the percentage of managed devices without Antivirus installed.
The Affected devices expander a graph showing all managed devices which have no anti-virus installed,
those with anti-virus installed, and those which have anti-virus installed but do NOT have auto-protection
enabled.

Core Server Inspector – Health
The Health tab shows:
The Performance parameters expander, which shows the Management Suite service pack level, the last time
the core server was rebooted, scan files to be processed, scan files in the Error scan directory, the amount of
memory used by the LANDesk Inventory Server service, and the amount of memory used by the LANDesk
CoreSync service.
The LDMS installed patches expander shows the Management Suite patches installed on the core server,
including the patch name and file version.
The IIS application pools expander shows the Application pools and the Status (started or stopped).

Inspector for the Scheduled Tasks
To launch the Inspector for Scheduled tasks, select the individual task, right-click, and click Inspect.
Inspector for Scheduled Tasks

The General expander shows the task name, the package and delivery method (if using Software Distribution),
who last saved the task and when, the last run time, the next run time (if recurring) and the number of target
machines in the task.
The Job status expander shows a graph with the devices which have failed the task, the number pending,
those which are active and those already successful.
Inspector for Vulnerabilities
The Vulnerability tab shows:

The Properties expander the vulnerability ID, the date the vulnerability was published, the title, description,
Language, Info URL, FAQ URL, Vendor, Who last saved the vulnerability and the source.
The Affected devices tab shows:
The Vulnerability expander has a graph of the devices detected for the vulnerability, the devices which have
repaired the vulnerability, and the devices where the vulnerability failed to repair.
The Excluded expander shows the number of devices which have not been scanned for vulnerabilities.

Inspector for Queries
The General expander includes the name of the query, its criteria, who last modified the query, when the query
was last modified, and any and all tasks which use the query.
The Generated SQL expander displays the SQL command of the query.
Adding pictures of users to the Inspector

The Inspector can show pictures of the logged in user. The picture is displayed in a 72x72 image, and must be
in JPG format. If the images are larger, they are automatically scaled down. The photos can be added
manually or imported from Lightweight Directory Access Protocol (LDAP) sources like Active Directory.
To add pictures manually, copy them to:

C:\Program Files(x86)\LANDesk\ManagementSuite\image\inspector
To add pictures from an LDAP connection:
If the LDAP connection is already configured in Management Suite, the import will use the existing connection.
If a new LDAP connection is required it can be added in the console by:
1. Click Tools > Distribution > Directory Manager (The Directory manager tool opens.)

2. Click the Manage Directory icon. (The Active Directory source window opens.)
3. Click [Add].
4. Type the directory path in the LDAP field.
5. Type the User in the User name field.
6. Type the Password in the Password field.
7. Click [OK].
8. Run C:\Program Files(x86)\LANDesk\ManagementSuite\ldphotoimport.exe
(LdPhotoImport will query for pictures using the LDAP connection and will place them in the C:\Program
Files(x86)\LANDesk\ManagementSuite\images\inspector directory. Existing pictures will be
overwritten.)
Note
If you use LdPhotoImport you can schedule a task to periodically keep the photos up to date.
Creating Custom Inspectors

Documentation on how to create custom Inspectors is in the document Customizing the LANDESK
Inspectors which can be downloaded from the LANDESK Community website:
http://community.ivanti.com/support/docs/DOC-25070
Note: Support will assist with questions related to the examples of what is in the document. Support is NOT
scoped to design or troubleshoot any customizations or extensions of the Inspector beyond the customization
document. For custom solution please work with Ivanti Sales and Services.
There are hands-on exercises for the Inspector.

Management Suite Reporting
Module Objectives
 State what Dashboards offer

 Cite the Types of Reports Available
 Describe options in the Report Viewer
 Describe options in the Report Designer
 Name where to go for additional Report resources

Overview of Reporting
Having accurate and reliable information is essential to making good business decisions. Reporting plays a
role in various facets of IT. It is for this reason that Management Suite has such a powerful and robust
Inventory management tool, integral to the product.
Assets can be tracked from order placement, to receiving, to provisioning, to placement into the organization
and eventually to their disposal. Hardware warranties and software licenses can be tracked. Management
Suite automates many aspects of reporting. By scheduling reports, information can be delivered to a web
server, file share, or directly to a decision maker’s inbox. Reports can be produced in a variety of formats.
The reporting tool can be used to generate a wide variety of specialized reports that provide critical information
about the devices on your network. The reporting tool takes advantage of the Management Suite inventory
scanning utility, which collects and organizes hardware and software data. This enables the creation of useful,
informative, and up-to-date reports. You can schedule reports so they run at an interval you specify, and these
can be stored in a share or e-mailed directly to users.
Dashboards provide essential “at-a-glance” reporting that is so valued. Viewing a dashboard to almost instantly
gain insight on projects, status, and progress is almost priceless. Management Suite enhances the
administrator’s ability to create and configure dashboards.
Dashboards
Dashboards give management and IT personnel ability to see both trends over time as well as a way to easily
identify items which may require immediate attention. Before dashboards, exhaustive searching of voluminous
logs and chatty notification alerts were the standard mode of operation. Dashboards give the ability to
configure what graphs the dashboards contain, as well as making it easy for IT personnel to quickly see what
requires immediate attention.
Design your own dashboard to report on various aspects under your prevue of management. You can build
dashboards for different categories such as: Windows upgrade, Software Distribution, Security, Remote
Control, Power Management, Rollout Projects, Patching, Software, Operating Systems, etc.
Configure dashboards in the Console by selecting Tools or Toolbox > Reporting / Monitoring > Dashboard
editor. This opens the Dashboard Editor tool. Create new dashboards available to groups by membership as
with other tools in the Console. When you select to create a new dashboard the following tools help you to
accomplish the task:

Selecting to Add charts to dashboard gives you access to over 100 selectable graphs. Chart colors lets you
customize what colors you want graphs to contain, making it easy to pinpoint items needing immediate
attention.
There is a hands-on exercise to configure a dashboard.
Charts
A number of tools accessible in the Management Suite Console provide charts to give quick overview of status
and activity. Graphs can be added to the chart views and colors can be modified just like for dashboards.
Workspaces
The addition of workspaces gives users access to information which takes into account the rights that are
granted to each specific user. For each user, pertinent information, based on their role, is presented in the
workspace.
The workspace is accessed by opening an internet browser and going to:

http://[Core_Name OR IP_Address]/my.bridgeit.

If you log in as the Management Suite Administrator, you are granted access to the IT Support Analyst
workspace.

Task Overview
The Task Summary workspace view populates with the following graphs:
 My Tasks – Last 24 hours: Status of tasks created by the login user in the last 24 hours
 All Other Tasks – Last 24 hours: Status of tasks created by all other users in the last 24 hours
 My Task List – Last 24 hours: Names of tasks created by the login user in the last 24 hours
 All Other Task List – Last 24 hours: Names of tasks created by all other users in the last 24 hours
The graphs populate real-time and can be clicked to drill-down to see the items populating the data.

Asset Manager – Software Optimization
The Software workspace view populates with the following graphs:

 Current State of Compliance: Compliance based on all products being monitored in Software License
Monitoring
 Money Saved: Amount of money saved due to reclamation being used in Software License Monitoring
 Save Money: Amount of money that could be saved if reclamation was utilized in Software License
Monitoring
 License Optimization: Licenses in use based on Software License Monitoring
 Top 5 Out of Compliance - Installations: Top five products monitored which do not have sufficient
associated licenses in Software License Monitoring
 Top 5 Out of Compliance – True Up Cost: Cost to buy licenses to bring the top five products out of
compliance to be within compliance

Expiring Hardware
The Hardware workspace view populates with a graph showing Devices ready to be refreshed, based upon the
warranty data listed for the items listed.
The listed items can be clicked to drill-down to see more in-depth data.

Software Licenses
The Software Licenses workspace view populates with a graph showing devices monitored in Software
License Monitoring.
The listed items can be clicked to drill-down to see more in-depth data.

Security Manager – Security Dashboard
The Security Dashboard workspace view populates with the following graphs:
 Devices With Vulnerabilities: Graphs devices by vulnerability level

 Vulnerability Scan – In Last 30 Days: Graphs devices by vulnerability scan status in the last 30 days
 Inventory Scan – In Last 30 Days: Graphs devices by inventory scan status by device in the last 30 days
 Most detected Vulnerabilities – In Last 30 Days: Graphs detected vulnerabilities by device in the last 30
days
 Most Failed Vulnerability Repairs – In Last 30 Days: Graphs failed vulnerability repairs by device in the
last 30 days
 Devices with most Vulnerabilities – In Last 30 Days: Graphs devices with the most vulnerabilities in the
last 30 days
 Devices with Most Failures – In Last 30 Days: Graphs devices with the most failures to remediate
vulnerabilities in the last 30 days

Self Service - Software Catalog
The Software Catalog workspace view shows software scheduled and is complete with a search feature.

Self Service - Launchpad
The Launchpad workspace view shows items scheduled to the Launchpad and is complete with a search
feature.

Self Service - Document
The Document workspace view shows documents scheduled and is complete with a search feature.

Administration – Manage Users
The Manage Users workspace view shows users on the managed device, has an add user feature, a delete
user feature, and is complete with a search feature.

Administration – Dashboard Designer
The Dashboard Designer workspace view shows Analyst Workspace, Asset Manager Workspace, Security
Manager Workspace, Self Service Workspace, and has ability to add items each Workspace view.

Administration – Connectors
The Connectors workspace view shows items with which the connector can link. It lists the Applications,
Status, Last Sync Date, and Vendor.

Administration – Theming
The Theming workspace view allow you to choose choose the theme for all Workspaces. (Choices include the
ability to select the Default, Dark Blue, Dark Orange, or create a Custom theme. It also includes the ability to
select the Corporate Graphic logo to use in the Workspace, the Main Application Background Image, and the
Login Screen Background Image.
There are hands-on exercises for Workspaces.
Reporting in Management Suite

Reporting formats:
When running a report, you can print the report, or export to an HTML format. When you schedule a report in
the Reports tool, you can use the following formats:
 PDF: Adobe PDF file

 XLS: Microsoft Excel file
 DOC: Microsoft Word file
 CSV: Comma-separated value text file

 HTML: Hyper-Text Markup Language (web-based) file
Saved reports can be made available through a web share, a UNC share, or e-mailed directly to a user.
Launching the Reporting Tool

The Reporting tool can be launched from the Direct Console, the Remote Console, and the Web Console.
To launch the reporting tool from the Core Server Console or the Remote Console:
Click Tools or Toolbox > Reporting / Monitoring > Reports.
To launch the reporting tool from the Web Console:
Click Reports under the Reporting group.
When you use the Web Console, the reports created in the Direct and Remote Consoles are available to you,
but you cannot edit or create a custom report in the Web console, nor can you move reports between folders.
What you can do is execute, view, and export reports.
Types of reports available:

 One-click (ad-hoc) reports: One-click reports are available from various areas of Management Suite. For
example, you can create a report based on a device group, a query, or from tools.
 Standard (predefined) reports: Default reports that ship with Management Suite.
 Custom reports: Custom reports that define a unique set of information to generate a report. You can also
customize any of the standard reports.
One-click Reports
One-click reports are available for most items in the Console. Any group or container (such as query, or
devices) has an option for simple report creations. The report displays the data in the current view, organized
using the data columns displayed in the Console. You can also run a report for many of the tools, showing the
items in a particular view (such as a list of alert rulesets in the alerting tool, or devices in the scheduled tasks
tool). There are three (3) types of one-click reports:

 View As Report: Right-click an item and select View As Report to view the data in a standard report
format. A report preview window opens, and you can select different options before printing, saving, or
sending the report.
 Export as CSV: Right-click an item and select Export as CSV to save the data in a comma-separated-
value file.
 New report: Right-click a query and select New Report to create a new report based on the query. You
can use a standard format or open the report designer to further customize the report. The new report is
saved in My reports.
Standard (predefined) Reports

When you installed the Core Server, a set of well over a hundred standard reports was immediately made
available to you. These reports cover the following groups:
 Agent watcher: Presents reports of devices where Management Suite required services are not running,
or where monitored files are not found.

 Benefit analysis: Presents reports of devices upon which remediations took place, patches were
deployed, remote control was used, and software was distributed.
 Content replication: Presents reports of replication tasks and preferred servers, replicators, and sources.
 Distribution status: Presents delegated tasks, and reports of software delivered by device and task
status.
 Download statistics: Presents reports of downloads by type, and downloads over time
 Hardware password manager: Presents reports and audit information of devices with hardware password
manager enabled.
 Inventory: Presents thirty (30) reports concerning inventory information.
 Power management: Presents reports of power management alerts, coverage, and historical data.
 Remote control: Presents summary or detailed reports of managed devices which were remotely
controlled.
 Security: Presents reports for various security tools including: antivirus, blocked applications, compliance,
custom definitions, host intrusion prevention, Management Suite updates, security threats, spyware, and
vulnerabilities.
 Software license monitoring: Presents eleven (11) reports about licensing including: group software
costs, products installed but not used, various views of software usage, and various views licensing
compared to use.
 Unmanaged devices: Presents reports of devices discovered across the enterprise.
 Vendor: Presents reports on HP devices including battery, point-of-sale, power consumption, and secure
erase provisioned status.
New Custom Report

The new custom report feature provides ability to Console users to create a report. In order to simplify the
process of creating new reports, a right-click feature was added to queries, which launches the Report
Properties with a button to immediately bring the query into the Report Designer.

This feature makes possible the creation of detailed reports with the versatile features of the Report Designer,
without having to know, edit, and create SQL queries from scratch.
Report groups
The Reports tool is where the main body of reports is accessed.
Reports are organized with a tree structure, grouped in the following folders:
 My reports: Contains reports that the current user has created or copied from another folder. These are
typically reports that you run on a regular basis and have organized for your own use. You can organize
reports in folders that you create. Management Suite administrators have access to each user’s reports
groups and can add and remove reports as desired.
 Standard reports: Contains predefined reports that are installed with Management Suite. The reports are
preformatted, have query properties, and chart types assigned, and are ready to be used.
 Public reports: Contains custom reports that are made available to all users who are granted access to
the Management Suite console and have been granted the Reports – View right.
 All reports: Contains all reports that can be used by the current user. This view includes a Find box that
filters the list of reports when you type a search string and select a column. (For example, type “license”
and select the “Description” column to view reports related to software licenses.)

Management Suite Administrators can view, edit, and delete the contents of any of the report groups. Users
with the Reports right can also see and run reports, as well as publish reports, but only on the devices included
in their scope. Users with the Report designer right can create custom reports. Reports are run against the
currently logged-in user’s scope.
Dashboard Sub-Reports
Dashboard sub-reports are detailed reports available from graphic charts of a dashboard widget. Under
Security, Antivirus provides access to the Antivirus dashboard. If you select Antivirus dashboard there are
dashboard charts of Real-time scanner status, Virus definition status, and Recently scanned. If you
double-click any of these three charts, the detailed sub-report of supporting data will appear.
Report Properties
When you create or edit a report, you first specify the report properties.
 Title: Type a descriptive title for the report.

 Description: Add any other descriptive information for the report.
 Load from LDMS query: Select a Management Suite query and use it as the basis for a new report.
 Report designer: Open the report with the options you have selected in this dialog box.
 Preview: View the report with the options you have selected in this dialog box.
If you have copied a standard report, you might simply change items in the Properties dialog box and save the
new report, or conversely you may want to open the report designer and make more substantial changes.
The Report Viewer

When you run a report, the report viewer launches and displays the generated report. This report viewer
provides controls that let you display the report according to your viewing preferences. You can also export a
report from the report viewer or save it in a different format for distribution.
The report viewer includes a toolbar and a sidebar. The toolbar consists of the following buttons:
 Open report: Lets you select to open previously saved reports.

 Export: Opens dialog to export as an Image (BMP, EMF, GIF, JPEG, TIFF, PNG) Html, PDF, XML, Word,
or Excel.
 Copy: Copy the contents of the report for the selected page.
 Print Preview: Shows a preview of the report.
 Page Setup: Opens dialog to select page, layout, and watermark settings.
 Print: Opens the print dialog to select the printer and print settings.
 Show or Hide sidebar pane: Toggles on or off the sidebar pane.
 Back to parent report: Returns you to the parent report if you opened a child report.
 None: Shows what is selected from a report.
 Pan mode: To pan in a report.
 Selection mode: Selects a portion of the report.
 Snapshot mode: Selects snapshot mode for the report.
 Zoom in mode: Increase your view in a report.
 Zoom out mode: Decrease your view in a report.
 Current zoom: Shows the size of the current zoom in a percentage.
 First page: View the first page of the report.

 Previous page: View the previous page of a report.
 Current page: Indicates the page number you are viewing and the total number of pages in the report.
 Next page: View the next page of a report.
 Last page: View the last page of a report.
 Cancel: To cancel the previous action in a report.
 Refresh: Refreshes the view of a report.
 Find: To search for select words in a report.
The Report Designer

The Report Designer provides the unique ability to create and edit reports, and it executes SQL commands.
Users with rights to the Report Designer are given rights to the Core Server’s Database. It is possible that data
could be lost or corrupted if a user executes SQL commands to modify data, so caution should be used by
those who are granted rights to the Report Designer.
The Reports tool accesses the database with the user credentials that were specified during product setup.
These credentials can be managed in the Configure LANDESK Software Services dialog box. If you prefer
to set up different credentials for the users who have reports rights, you can create a second set of credentials
for reporting database access. (For example, if you want report users to have read-only access to the
database, you can create a user in the database using the Database’s Management Tool, and enter the user
information in the User name and Password fields in the Reporting database user section on the General
tab of the Configure LANDESK Software Services dialog box.)
The steps to specify a database user credentials for reporting are as follows:
1. Create a user account for the Core Server’s database, assigning it the rights you want that user to
have. (This is done with the Database Management Tool used for the Management System chosen.)
2. In the Management Suite Console, click Configure > Services.
3. Click to select the General tab.
4. Under Reporting database user, enter the User name and Password for that account.

5. Click Apply.
Using the Report Designer

From the report properties dialog box you can open the Report Designer. The Report Designer includes an
integrated Data Dynamics report to give you full control over all aspects of the report. The Report Designer is
integrated with the Reports tool and the database. (Note: for a Console User to open the report designer, they
must have the Report designer – Edit right.)
In the Report Designer you integrate page layout elements linked to data objects to display selected data. The
Report Designer provides customization of the report appearance, the underlying SQL query statement, and
the parameters available to users.
You can create or modify a report by doing one of the following:
 Copy a standard report, paste it into My reports, and edit it.

 Create a query in the Console and use that query as the basis for a report.
 Create a completely new report using data sources, parameters, SQL expressions, page layout elements,
and images.
Elements defined in the Report Designer include the following:
 Toolbox: Drag a tool onto the page layout to place the object.
 Data sources: Specify the data sources you want to use when running the report. Define the source of the
data and then add data sets (queries) and parameters that you will use in the report.
 Report - Parameters: Define parameters that determine report results.
 DataSet: To view properties of a DataSet.
o General: Modify general properties
o Query: Set records query and options
o Options: Set query command data options
o Fields: Modify dataset field aliases and modifiers
o Parameters: Modify query parameters
o Filters: Modify dataset record filter conditions
Basics of creating and editing reports

The report designer is a flexible and feature-rich tool that gives you options for querying and displaying data
from a variety of sources. When you create a report, you need the following basic items:
 A data source and defined data sets from which the report is populated
 A page layout to visually display the data
 Data regions and other report items that format the data
Data sources and data sets

Reports extract information from the data source, a database using a standard format such as SQL, ODBC,
Oracle, or XML. In combination with the data source, you define the data sets, queries that are referenced in
the report. The data explorer on the left side of the designer shows data sources and data sets in a tree view.
In the example below, LDMS is the data source (the Management Suite database) and Windows Devices is a
data set. Name and Version are names of fields (database tables) referenced in the data set query.

The Management Suite database appears as a default data source when you create a new report. You can
add any other source by specifying a data type, a connection string, and any credentials needed to access the
data. This allows data to be extracted not only from the Management Suite database but any other source as
well when you create a custom report.
Parameters pass information between data sets. In the report viewer, parameters can be displayed to let the
user narrow down the selection of data displayed.
Adding data elements

The report designer includes wizards to help you link to data sources and define data sets and parameters. For
example, when you click on a data source (such as LDMS), click the Add button and select Data Set.

The DataSet wizard is displayed with properties organized in six groups.
On the Query page, for example, you can edit the SQL query.
Report items
Items in the toolbox are used to format the page layout and place data on the page.

 Pointer
 Banded List
 Barcode
 Bullet
 Calendar
 Chart
 Formatted Text
 Image
 Line
 List
 Matrix
 Rectangle
 Sparkline
 Subreport
 Table
 TextBox
These elements are fully customizable and can be combined in many ways to group and display data.
For ideas on how you can define your own reports, view the properties for any standard report and click
Report designer to see how the report has been defined.
For Additional report resources

For more information on using Management Suite reports, go to the Management Suite User Community's
reporting portal at http://community.ivanti.com/ldmsreports. This provides a link to where customer can share
reports with other customers.
To quickly open the Ivanti User Community reporting portal, you can also click Tools > Reporting/Monitoring
> Community reports.
Information is also available on the Data Dynamics Reports Web site at http://www.datadynamics.com.
There are hands-on exercises for Reporting.
Check for Understanding concerning Reporting

1. What business cases most demonstrate the positive impact of being able to create your own dashboard?
2. How do you create your own dashboard and add charts of your own selection in Management Suite 2016?
3. How do you pull up workspaces on a managed device in Management Suite 2016?
4. What types of information do workspaces make available, and how is this helpful in a business
environment?

Software License Monitoring
Module Objectives
In the Software License Monitoring section, you will learn:
 Cite use cases for the Software License Monitoring

 List features and functionality of Software License Monitoring
 Describe the Architecture of Software License Monitoring
 Describe Agent Configuration in Software License Monitoring
 Configure Role-based Administration in Software License Monitoring
 Navigate the Software License Monitoring Tool
 List steps to implement Software License Monitoring
 Describe how Ivanti Data Analytics affects Software License Monitoring
 Troubleshoot Software License Monitoring

Use Case
Your company was just informed that it will be audited three weeks from today by a certain software company.
To prepare for the audit, the Chief Informational Officer (CIO) wants reports detailing which managed devices
in the company have software from the auditing company installed on them. The CIO also wants reports
showing software from certain other companies to assure there are enough licenses, should the other
companies decide to audit.
Additionally, with Software as a Service (Saas), some software which was purchased is not stored locally or on
the network, but rather is accessed via the internet. The CIO wants a report detailing which users and devices
access the internet site where software is available as a service.
IT Administrators often find it challenging to track product licenses installed on numerous managed devices
throughout the network. They run the risk of not only over deploying product licenses (having more copies
installed than licenses purchased), but also of purchasing too many licenses for product that is not installed
and therefore not necessary. Either is a money-risk to a company. Compound that by the fact that some users
use software for a time, then they don’t need that software anymore. Reclaiming software from a user who no
longer needs it, and giving it to a user who does, saves software costs.
Walking the fine line of having enough but not too many licenses is always a concern. With the need to
forecast and be accountable for a budget, licensing costs, as well as upgrade costs must be taken into
account. Having this knowledge of software can greatly affect budget management and save money over all.
Features and Functionality

Software License Monitoring (SLM) features include:
Passive, low-bandwidth monitoring: The Software Monitoring agent passively monitors product usage on
managed devices, using minimal network bandwidth. The agent continues to monitor usage for mobile devices
that are disconnected from the network.
Automatic discovery of applications present in the environment: Users are not required to manually
define software products or import pre-defined content. Automatically discovered products are a reflection of
what is found in the environment – no inapplicable content to deal with. The date a product was discovered is
tracked, as well as when it was last used. Updates or patches to a software product are automatically handled.
Software accessed via the Internet: With some software being stored on a website outside of a company
(Software as a Service, or SaaS), Software License Monitoring can track devices and users that access such
pay-for services.
Reporting: The power of compliance monitoring rests in its data-gathering capabilities. Use the gathered data
to track and report on overall license compliance, to monitor product usage, and report access to software.
Reclamation: Software License Monitoring has the ability to uninstall software from devices no longer using
that software, in order to free up licenses for audit compliance, and lower cost true-up.
Allocations: Software License Monitoring includes the ability to provide a way to track license and support
costs to groups across an organization.

Architecture
Software License Monitoring is an extension of the software inventory process. It includes an agent component
on the managed device that tracks applications that have executed. It tracks when the software was first
discovered, the last time the application launched, and for how long it ran. It also tracks the total number of
times the application launched and the total duration.
This software usage data is stored on the managed device and is not delivered to the Core Server until a
software inventory scan completes. Application usage is tracked even if the device is not communicating with
the Core Server or even connected to the network. So in a passive way, the managed node tracks software
activity locally, and reports it to the Core Server, in a low bandwidth consuming way with each software
inventory scan.
The agent component central to Software License Monitoring is the softmon.exe file. The softmon.exe file
registers and installs as the LANDESK® Software Monitoring Service on the managed device and monitors
all processes that are launched. It writes the usage information to the registry, in
HKLM\Software\WOW6432Node\LANDesk
\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog. GatherProducts.exe then runs on the
managed device, to gather software usage. It stores the resulting file in
C:\Program Files (x86)\LANDesk\LDClient\Data\GatherProducts.txt. The scans looks at the Windows
registry uninstall keys, .MSI files, shortcuts, and GUIDs to identify software. It can be configured to also gather
usage via Web Sites offering SaaS. Any new application is recorded and any repeating application is updated
with its usage information.
As an extension of inventory, Software License Monitoring relies on the LdAppl3.ini file to deliver software
information on the managed device. The settings instruct the managed device to send data on specific
applications. It is not telling the managed device which applications to monitor. The agent monitors all
executed software. The agent sends only the data on the software requested by the Core Server.
To provide maximum flexibility, Software License Monitoring includes a container object to monitor
applications. This is referred to as a Monitored Product (often referred to as Product). The Product refers to
an application that has been setup to be monitored for licensing and usage information.
Vendor names often vary, even within a single company. Many times in the Software License Monitoring tool,
the same manufacturer is listed with different variations. Microsoft Corporation, for example, is listed more than
a dozen multiple ways. In addition, as companies are acquired by a larger company, software of the acquired
company can be reported with the parent company (e.g. FRx Software Corporation, and Great Plains Software
Inc., who were both acquired by Microsoft). Creating a normalized group which includes all variations of a
vendor name provides the ability to track associated products by software vendor. The benefit of this feature is
to have a larger pool of products under one manufacturer to reduce the size of the overall manufacturers list.
Agent Configuration for Software License Monitoring

The Software Usage Monitoring window in the Agent Configuration tool enables Softmon.exe to load on the
managed nodes. This enables tracking usage statistics for Software License Monitoring as well as collecting
additional inventory information. Softmon.exe also blocks applications when application blocking is configured
in the Patch and compliance tool.

Also available in the agent configuration for Software License Monitoring is the ability to record software usage
statistics to a network location. This feature is critical for non-persistent Virtual Desktop Interface (VDI)
environments. In a non-persistent VDI environment, each time the non-persistent VDI device is rebooted, it is
returned to a previous snapshot, including any registry settings or modifications. Since Softmon.exe records
usage data in the registry, the snapshot process deletes the software usage data. The setting to record to a
network location means the tracked usage data is stored to a network location, which is not affected by the
snapshot, so the data is not lost but rather is accumulated and reported to the Core Server when the Inventory
scan, which includes software, is run.
Role-Based Administration for Software License

Monitoring
The Software license monitoring permission provides the following levels of access to users:
View: Allows the user to see and access the software license monitoring tool from the Console
Edit: Allows the user to create or change software license monitoring settings and configurations

Navigating the Software License Monitoring Tool
The Software License Monitoring Tool is accessed by going to the Management Suite Console and clicking
Tools or Toolbox > Reporting/Monitoring > Software License Monitoring OR by going to the Toolbox and
going to the Reporting/Monitoring Group and selecting Software License Monitoring.
The Software Licensing Tool has four principal areas represented by their respective tabs:
 Dashboard: Grants access to three groups of reports with graphs which can be printed or exported to CSV
o Audits: Top total installations
o Compliance:
 Top out of compliance by installation
 Top out of compliance by true-up costs
 Top out of compliance by manufacturer
o License Optimization:
 Estimated savings from never used installations
 Top 5 software harvest opportunities.
 Products: Lists four different software product groups:
o Monitored: Lists all monitored products which can be searched by Manufacturer, Product, or
Computer Group (query or device group)
o Discovered: Lists all discovered products in the database minus those ignored
o Ignored: Lists all products deemed to not be important to you, removing them from discovered
o All installed products: Lists all products in all three previous groups.
o Licenses: Lists all the licenses input or imported. These can be searched by Product, Computer
Group, or Vendor, to compare licenses with usage.
o Reclamation: Lists all products set up for reclamation.
o Allocations: Show all products allocated to groups, by group.

 Administration: Accesses five features
o Computer Groups: Sets up to Track license use by Queries, Device Groups, or All devices
o Manufacturers: Manage and group similar company names into a combined company or change an
acquired company to be listed under the owner company
o Calculations: Accesses three features:
 Usage, license and compliance: Calculate product installation and usage immediately when
saving a product, or manually.
 Publish product detection information for client scanning: Update the LDAPPL3 files.
 Run reclamation: Reclaim licenses not currently being used.

o Email Settings: Set the SMTP server, and Sender email address (used in reclamation).

o Reclamation Defaults: Provides ability to configure reclamation.
 Delivery method: Specifies the delivery method which will be used to uninstall the software which
is reclaimed. Click Browse to view the available delivery methods.
 Distribution and patch setting: Specifies the distribution and patch settings which will be used to
uninstall the software which is reclaimed. Click Browse to view the available settings. Specific
configurations used as set with the selected settings include:
- Network settings to determine the Preferred server / Peer download options to access the
application to be used for the uninstallation.
- Policy sync schedule to determine when to uninstall the application.
- Notification to determine whether the uninstallation is silent or verbose.
- Distribution-only settings to determine feedback and deferral options.
- Offline to determine whether to uninstall when offline.
- Logged off user options to determine whether to uninstall when logged off.
 Reboot settings: Specifies the reboot settings which will be used to uninstall the software which is
reclaimed. Click Browse to view the available reboot methods.

 Only reclaim if the product has not been used in ### days: Sets the number of days a product
will have to not be used in order to be reclaimed. (The default is 120 days.)
 Click to select Start scheduled tasks immediately after creation to automatically start
uninstalling products that meet the reclamation criteria.
 Reclamation Thresholds: Allows settings to either:
- Reclaim from all machines that have not used the product in specified days since last
used.
- Reclaim to maintain a set of free licenses: When available licenses is less than ## create a
task to reclaim until up to ## licenses are available, run reclamation process every ## days.
(Selecting the reclamation process to run every 0 days, sets it to run daily.)
 Run reclamation process every ## days: Specifies how often to run reclamation when it is
enabled. (The default is 14 days.)
 Computer Groups that will be used in reclamation: Configure computer groups to be included
and/or excluded from the reclamation process. Computer groups are set up in Administration >
Computer Groups. (Unlisted computer groups are excluded.)
 Enable email notification: Select this checkbox to enable sending an email to administrators or
other users you add to the Email recipients field to inform them of reclamation having been run.
 Reports: see the Reports section below.
Steps to Implement Software License Monitoring

The steps to begin using Software License Monitoring are as follows:
1. Normalize the Vendor – Combine into a normalized group any vendors which were left out of the
normalized group, but need to be added to the combined group.
2. Set Products to Monitor – Set Discovered products into Monitored to compare with licenses.
3. Add Licenses – Add licenses for Monitored products.
4. Set up Allocation (optional) – Track licensing usage by device group or query.
5. Set up Reclamation (optional) – Set options to reclaim software licenses not in use or no longer needed,
by removing software from managed devices.
6. Run Reports – To see Audits, Compliance, and License Optimization reports.
Normalize the Vendor

One of the dashboard options is the “Top out of compliance by manufacturer” report. If you are preparing for an
audit of that manufacturer, and you are missing some of the software from that manufacturer, the results could
be devastating. Before you start digging into software, check to see that the normalized vendors are as
inclusive as they should be.
The vendor list will grow as additional software is found by inventory, so it is a good idea to periodically check
the vendors not in a normalized name.

Vendor names very often vary in subtle ways. For example, some variations of Adobe Systems Incorporated
include:
 Adobe
 Adobe Inc
 Adobe System Inc.
 Adobe Systems Inc
 Adobe Systems Inc.
 Adobe Systems, Inc
 Adobe Systems, IncTo combine the separate vendor names into one, create a normalized vender name,
and drag-and-drop all corresponding and applicable vendor names into the normalized name.
To view the vendor list, and possibly add or delete a vendor from the normalized list, do the following:
1. Open the Software License Monitoring tool
2. Go to Administration, and then Manufacturers. All the normalized vendors in the list have a + in front.
3. Type a vendor name in the search manufacturers box, and click enter (e.g. Adobe).
4. You can add items to normalized vendor by using drag-and-drop. You can similarly remove items the same
way.
Set products to Monitor

The product list will grow as additional software is found by inventory. The inventory looks for software by
scanning the Windows registry, uninstall keys, .MSI files, shortcuts, and GUIDs. It can also be set to gather
usage via Web Sites offering SaaS. The goal, of course, is to populate inventory and software license
monitoring with all discovered software.
The goal of the Administrator then, is to be sure to monitor all software which is in the domain and requires
purchase of a license. A good place to start is with Accounts Payable. Any software purchased should be
monitored. Additionally, software in use, which requires but does not have a license, should be monitored.
Ivanti facilitates searching these out, with the excellent discovery mechanism built into the Inventory tool.
Normalized Product
When setting products to monitor, you can create a normalized product. The two key components used when
searching for this product are the product name, and the version. Either field or both fields can use wildcards.
An additional way to search is to add contained products. This allows a search using either of two criteria,
namely: product name contains, or product name does not contain. The search brings all products into a
list which satisfy the criterion used, and the desired products and associated versions can be selected from the
list. The list has an additional checkbox, show only monitored products. If the box is unchecked, all
discovered software products that match the criteria are listed, but if checked, only the monitored software
products that match the criteria are listed. This allows a thorough way to normalize a product
Custom Product
When creating a custom product, there are four items to complete:
 Definition: Here you set designations for the custom product you are adding. Fields in the Product name,
the Version, the Manufacturer, and the Status (Monitored, Discovered, or Ignored).
 Installation detection: Here you define the way software license monitoring determines if the product is
installed. There are three ways to define whether the product is installed.
o Searchable by Query: Create a Management Suite query to match software criteria
o File detection match any: Determines the product is installed if ANY of the defined files are present
on a managed device.

o File detection match all: Determines the product is installed only if ALL the defined files are present
on a managed device. This is the way to distinguish, for example, Microsoft SQL Server Express
(which is free) verses Microsoft SQL Server (pay for version).
For either of the file detection methods, you can add products selecting from a list of file names and versions,
or by defining a new file by using a file name, version, and size (in bytes).
 Usage detection: Here you define how software license monitoring accumulates usage information for
when the software was last used, and the time the software was in use. There are two ways to select
these. The first way is to select from a list of file names and versions. The second way is to define a new
file by name, version and size (in bytes).
 Unit price: Here you set the cost of the custom product. This is used in reporting.
Add Licenses
When you add licenses, they can be measured against all managed devices, or against a computer group
(query or device group). This facilitates tracking licenses by geography, business group, business hierarchy, or
as an entire company.
Set up Allocation (optional)

When you add licenses, they can be measured against all managed devices, or against a computer group.
Set up Reclamation (optional)

Reclamation is a way to uninstall software which has never been used, or has not been used for a variable
amount of time which can be configured.
In order to set up reclamation:

 Reclamation Defaults: the configuration settings for reclamation
 Software Distribution: must be configured with:
o Distribution package: the uninstallation package to remove the software
o Delivery method: to launch the uninstall package
 Computer Groups: that include devices from which software will be reclaimed
 Email notification (optional): to send an email when reclamation occurs
 Product: to identify the product to be reclaimed, and set all previous setup in motion
Reclamation Defaults
The first step to setting up reclamation is to set the Reclamation Defaults in the Software License Monitoring
tool, under Adminstration > Reclamation Defaults.

Software Distribution
Create, or point to an existing Delivery Method, Distribution and patch setting, and reboot setting.
Create, or point to an existing uninstall Distribution Package in Software Distribution. This is referred to in
the Reclamation Defaults.
Computer Groups
Set up Devices or Queries to be included or excluded from reclamation.
The Computer Groups are set up in the Software License Monitoring tool, under Adminstration >
Computer Groups.
Product
Product is configured in the Software License Monitoring tool under Products > Monitored (it is likely you
would be monitoring the product).
1. Select the product.

2. Right-click and click Edit.

3. Click Reclamation and setup the desired settings.
4. Click Task.
a. Browse and select the Uninstall package which will run the uninstall on the managed device.
b. Select the Delivery method to be used. (The default will be present from the Reclamation Defaults
settings.
5. Select whether to Start scheduled tasks immediately after creation.
6. Optionally, select the Reinstall package task.
7. Click Advanced.
a. Click all groups you want to Include in reclamation. (Note: you must choose either all to include or all
to exclude. But select only one or the other.
b. Click whether to select Enable email notification, and Email reciptients.
8. Click Task.
9. Click [Save].
Reports
The reports available to software license monitoring are classified into three groups:
 Audits: Reports for the following:
o Audit flags for:
 Licenses
 Products
o Licenses without:
 Manufacturer invoice
 Purchase date
 Purchase order number
 Unit price
o Monitored products without licenses
o New products discovered
 Compliance: Reports for the following:
o Compliance details: Details of software compliance for all licenses and associated products
o Compliance overview: License consumption for all monitored products
o Compliance total costs: Estimated cost of compliance for all monitored products with unlicensed
installations
 License optimization: Reports for the following:
o Computer group software cost: Cost of software licenses for specific computer groups
o License report: Details of all licenses
o Licenses with expiration data renewal cost: Cost of renewing licenses expiring before a specified
date
o Licenses without expiration date: All licenses that do not have an expiration date
o Never used installations: Products that have been installed, but never used
o Products not used in n days: Monitored products that have been installed but not used in a
specified number of days
o Products used less than n times: Devices with specified monitored products that have been used
less than n times
o Software product usage: Usage of monitored products for specific devices
o Unused software licenses: Estimate of potential savings from unused licenses
o Unused software licenses by computer group: Estimate of potential savings from unused
software licenses listed by computer group

Software License Monitoring and Ivanti Data Analytics
Software licensing is a complex issue. Which license needs to be applied to a managed device which has
Microsoft® Word™? Was Microsoft Word installed as a part of Microsoft Office, Microsoft Office Professional,
Microsoft Professional Plus, or by acquiring an MSDN license?
Add to that the complexity of downgrading licenses. Some manufacturers support downgrading, while others
do not. If I have a License for version 10 of an application, but I have version 9 installed. Can I cover version 9
software applications with version 10 licenses until I upgrade? That all depends on whether the manufacturer
supports downgrading!
As you can see, how you apply a license to software purchased is more complex that just having a license.
Ivanti Data Analytics

Ivanti Data Analytics can use effective licensing logic to narrow down how many software licenses are needed
to be in compliance based on installed software. This is an important task because Management Suite shows
software that has been installed and/or launched, but with upgrades, updates, and suite products, a list of 40
software titles might actually boil down to needing just 4 licenses to be in compliance, as an example. The
automated data collection and application of Data Analytics rules applies EULA/software license normalization.
Licensed Software Analytics

Ivanti Data Analytics has built in rules which apply licenses to software in a manner which takes advantage of
Suite, Family, Downgrade, and MSDN licenses.
The process begins with the Management Suite Inventory Agent which gathers software from the Add or
Remove programs section of the registry, the MSI database also from the registry, and the information from the
software headers. The Data Analytics engine then can standardize and normalize the software data for
manufacturer names and software titles.
The process continues when the raw software data is analyzed against the End-User License Agreements
(EULA) of top software manufacturers. A new Licensed Software attribute is then created for each device to
list the effective software licenses needed for each computer.
Exception Handling
Ivanti Data Analytics provides a way to connect to Microsoft Volume Licensing for the purpose of downloading
a list of licenses purchased. In this download, each license ID is placed line-by-line for comparing licenses
against software usage. New to this feature is the ability to Run Now with Exception Handling which
provides an interactive processing mode for all exceptions to properly deal with each line the rule does not
understand. Sometimes a license may be a 50 count, or there is line item for the DVD medium for install, which
is not a license. The Run Now with Exception Handling enables the administrator to properly apply each
exception line interactively.

Software License Import
An additional way to import licenses purchased, for comparison to usage, is the by importing software
purchased from a vendor. Here data is mined to a .CSV file for import. This too, can be run with exception
handling for interactive processing for exceptions. This entire process enables concise, complete, and
accurate, license comparison reportable through Ivanti License Monitoring.
Software License Import provides a way to import and populate license data, in bulk, into Software License
Monitoring, for usage reporting. There are a couple of key factors to understand that will help us understand
the rules which add the licenses.
Adding Software Licenses Manually

When you have Ivanti Data Analytics installed, adding software licenses is done differently (and MUCH more
simply) than by those unfortunate users without such a wonderful advantage. Ivanti Data Analytics creates 0
count licenses, assigning correctly to software families, groups, and versions, in the proper hierarchy.
As you can see in this Acrobat 3D (v.8) license, Ivanti Data Analytics applies as required to Acrobat
Professional version 8, then 7, then 6, then to Acrobat Standard, 8, then 7, then 6, then Acrobat version 5, then
4. This takes into account the downgrading ability, and the Product family licensing, and all iterations which
need to be considered. While the license has 0 copies, the structure is configured so as licenses are added,
they will be applied correctly.
Those unfortunate users without Ivanti Data Analytics need to research to find the correct order and hierarchy,
then create each Software Product and version, one-by-one, and finally, build the license, placing all products
by version and family in the proper order. (Let’s hope they found that process fun.) They get to do this for every
product. Another downfall for those without Ivanti Data Analytics, each vendor may have different rules, and
some of those rules can change from time to time.

Vendor SKU
Since all vendors and resellers call their product something different, Ivanti Data Analytics will try to use the
vendor SKU to classify the product, since regardless of who sells the product, the vendor SKU remains the
same. For example, Adobe assigns a unique SKU for Adobe Creative Suite Master Collection 6. So when
Ivanti Data Analytics imports the Software License information, as long as the Adobe SKU is in the import file,
Ivanti Data Analytics should map it to the correct product in Software License Monitoring. What makes this
possible is the Product Key, which is what Ivanti Data Analytics uses to associate the license with the product.
Import Key
The Import Key is a unique column (or more than one unique column) that Ivanti Data Analytics uses, along
with the product key, to uniquely identify a record. That way, if an import is run multiple times, it will NOT create
a duplicate record. It is important that the Import Key be unique so the multiple records in the import file do not
get merged into one. For this reason, each imported rule must include the Import Key to import into software
license fields, assuring that an entry exists, but only once, in the database.
Description Key
The Description Key is used only during exception handling. With the new feature to Run Now with Exception
Handling, if lines that are imported don’t match a product in the database, a dialog is presented which will allow
you to map the SKU (product key) to a Licensed Software product, if it is not already defined (or place a
number of 0 or skip if the exception line is informational or some other non-license data). The Description Key
field is where the line is placed for you to view the line to make the designation.
Software License Monitoring Files (for Troubleshooting)

Server Side Log Files
C:\Program Files (x86)\LANDesk\ManagementSuite\Log\SLM.Routines.exe.Information.log
C:\Program Files (x86)\LANDesk\ManagementSuite\Log\SLM.Routines.exe.Licensing.log
C:\Program Files (x86)\LANDesk\ManagementSuite\Log\SLM.Routines.exe.log
Client Side Log Files

C:\Program Files\LANDesk\LDClient\data\gatherproducts.log
C:\Program Files\LANDesk\LDClient\data\proddefs\*.xml

Check for Understanding about Software License
Monitoring
1. When and how is Software License Monitoring populated with software titles and software usage data?
2. The Software License Monitoring tool and reports show no software usage at all, but inventory scans are
occurring regularly and are correctly populating the database. What needs to be done to capture software
usage and populate it in the Software License Monitoring tool?
3. What step should always be done immediately before running Software License Monitoring reports to
assure current and correct data?
4. How does Data Analytics enhance Software License Monitoring?
5. What are the steps to implement Software Reclamation in Software License Monitoring?

Software Distribution
Module Objectives
 Cite business solutions resolved by Software Distribution
 List components utilized in Software Distribution
 Describe Software Distribution Architecture
 Describe Scheduled Task settings
 List Software Distribution download hierarchy
 Configure Content Replication
 Describe how self-organizing multicast™ works
 List types of Software Distribution Packages
 Create Software Distribution Packages
 Use the Bulk Package Credentials Update tool
 Describe settings for Software Distribution
 Schedule a Distribution Package
 Set default Scheduled Task Settings
 Use the Portal Manager
 Use Reporting concerning Software Distribution
 Use Rollout Projects for Software Distribution
 Explain use of the Application Builder
 Troubleshoot Software Distribution
 Gather Core and Client logs for troubleshooting

Software Distribution Overview
Management is asking for all devices in the enterprise to use the most up to date version of the Microsoft®
Office Professional™ Suite. The transition needs to take place within the next 3 weeks. In testing, the
installation of the newest version consumed 2,000 Mb of network traffic, to get the updated version copied to,
and installed on the test PC. How do we get the update in place within the next 3 weeks? How do we do this
without overwhelming the network, and especially the WAN links? How do we update the occasionally
connected remote devices? These issues are all addressed in Management Suite Software Distribution.
Software Distribution provides the vital ability to centrally deliver software to managed devices across the
enterprise. The software can be stored centrally, and distributed from there, or delivered from shares local to
remote sites. Software Distribution includes options to install the software from a server initiated process
(push-based) or pulling the software from a managed device initiated process (policy-based). Software
Distribution supports multiple package types, and always minimizes the bandwidth required to deliver the
software. Installation of software can be automatic, or can be controlled by the end user.
Now that we can see the business solution provided by the software distribution tool, let’s discover how it
works, and how to set up and utilize it.
Software Distribution Components

There are various components which make up software distribution. They include:
 Vendor Software Package: the software purchased from a vendor
 Management Suite Distribution Package: the software packaged to be distributed
 Agent Setting (Distribution and Patch): the setting of how to install the software
 Scheduled Task: the task, set in the Management Suite Console, which matches the Distribution Package
with the managed devices to install the software
 Software source: The Preferred Server(s) with the software packages in a share

Vendor Software Package
The first fundamental piece is the vendor software package. This is software purchased and downloaded or
shipped from a vendor. The software may be built or modified using a package builder application (such as
Flexera Software’s Admin Studio).

Management Suite Distribution Package
The second fundamental piece is the Management Suite Distribution package. This gives such parameters as
the file location (including additional files), command line options, dependencies, prerequisites, return codes,
and metadata.
Distribution and Patch Agent Setting
The third piece is the Agent Settings set on each managed device. These include:
 Distribution and Patch: Options set in the Distribution and Patch agent settings are:
o Network setting: Select preferred server/peer download options and download speed settings.
o Policy sync schedule: Select when and how often PolicySync.exe runs.
o Feedback: Select whether to show full package interface, and whether to show successful or failed
status to the end user.
o User defer: Select whether installations are deferred until the next logon, and if software installs can
be deferred, how long snooze times will be.
o LDAP group targeting: Select whether LDAP group targeting is enabled or not.
o Offline: Select whether to install a package when the Core Server is unreachable.
o Logged off: Select whether to install software when users are logged off.
o MSI Information: Set where to find source .MSI files, if required for installation.
 Reboot settings: Options set in the Reboot settings are:
o General: Select whether the reboot is Always needed, Detect if it is needed, or act as if it is Never
needed.
o Prompt: Select whether to prompt the user before rebooting, allow the user to defer (snooze) the
reboot, and show an icon in the system tray when a reboot is needed.
o Automatic: Select whether to reboot if:
 Logged out
 Locked
 No response to reboot prompt
 Reboot deadline
 Limit automatic reboot to a time window

Decisions for what the settings should be are best planned if you include input from different Information
Technology groups including: Chief Information Officer, Network Admins, Server Admins, and Workstation
Admins. Keep in mind you can place different agent settings on various groups of workstations and servers.
Scheduled Task
The scheduled task, set in the Management Suite console, matches the Distribution Package to be installed
with the managed devices which are to install them.
The person scheduling the task Schedules a Distribution Package and begins the task. The package installs
with Local System rights regardless of user rights. The person scheduling the task does not need access to
shares containing packages, since the authentication access is set in the Preferred Server entry in the Content
Replication tool.
Software Source
The original software source is where the package is first placed to be able to be distributed. Management
Suite makes possible various staging locations on what is called a Preferred Server. These distribution
sources minimize the amount of bandwidth it takes to deploy software to various devices in geographically
diverse locations. The source and preferred servers locations store the packages on either a Uniform Naming
Convention (UNC) share or a Web share.
Software Distribution Architecture

Software Distribution involves services that communicate between the Core Server and the managed device.
The key components are:
 Core Server: The Core Server uses four main executables to manage Software Distribution (and Patch).
o SchedSvc.exe: The LANDESK Scheduler Service (often referred to as the Scheduler) launches
tasks using task handlers. It was re-written in version 9.6. It has new settings for self-monitoring and

can restart itself if memory exceeds a threshold (1 GB default) or if its main processing thread
becomes blocked (hard coded to 10 minutes).
o TaskHandlerProxy.exe: Acts as an intermediary process between the scheduler and the task
handlers. It was changed in version 9.6 to relieve memory and processing constraints on the
Scheduler. It sets status based on the return value of the various task handlers.
o PolicyTaskHandler.exe: Launched by the TaskHandlerProxy to process all Software Distribution and
Patch tasks except those which are CustJob tasks. (CustJob is used by Pre-9.6 devices and
Unix/Linux.) Various functions which the PolicyTaskHandler handles include:
 Sorting target devices in each task by IP address
 Performing discovery (rewritten and enhanced in version 9.6) that matches on DeviceID and any
MAC Address associated with each target device.
 Can use DNS resolution for discovery (when configured to do so).
 Runs in either of two modes: (Each mode allows for task cancellation, something not possible
prior to version 9.6.)
 Parallel – Processes multiple target devices simultaneously using multiple processor cores.
 Serial – Processes target devices in a sequential manner.
 Launches PolicySync.exe on each target device using the TaskID as a parameter.
 Managed Device: The device which receives the application, both files used for Software Distribution and
Patch were rewritten and improved in version 9.6. The task is sent from the core server. The task is basically a
small packet with a number in it. The number references an .XML file in the Core Server’s ClientPolicies
directory Located at:
C:\Program Files\LANDesk\ManagementSuite\landesk\files\ClientPolicies. The push task files are named
CP.#.RunNow.xml (with the # corresponding to what was sent in the task.) The policy tasks are named
CP.#.xml. If the .XML file is a task to install software, the client will launch SDCLIENT.EXE.
o SDCLIENT.EXE: Performs the package installation, the client-side software distribution task history,
and launches the inventory scanner for sending updated software information to the Core Server, after
distribution has completed.
o PolicySync.exe: Initiates a client-side policy check to see all policies which the scheduler has for the
managed device. This can include software distribution packages, patch remediations, provisioning, or
other tasks.
Scheduled Task settings

Default scheduled task settings are configured by accessing the Configure settings icon on the toolbar of the
Scheduled tasks tool. From there, select Default scheduled task settings.

o Push options: Here you configure the following three settings:
 Process up to (configurable number) computers per task simultaneously
 Maximum task run time (from 15 to 240 minutes)
 Enable verbose policy task handler logging
Accelerated push enables speeding up the distribution of tasks. Prior to this, push distributions built up
a target list of up to 64 devices. These would be processed, and after each was completed, the task
would then move to the next 64 devices in the target list. Accelerated push makes this process
asynchronous. As the core discovers and communicates with target devices, it tells them what to do
and then moves on to the next targeted device without waiting for the job to complete. This discovery
and communication process uses multiple processor cores and threads. Each device, after receiving
the task from the core, processes the job and sends its status to the core when complete.
This accelerated push option of not having core wait until devices complete the tasks before sending
the task to additional devices makes the accelerated push setting to process up to 64 computers per
task simultaneously sufficient for most enterprise environments. In testing at Ivanti headquarters, a
distribution task to 20,000 devices completed in less than 10 minutes using the accelerated push
technology. Prior to using the accelerated push, the same task took more than 8 hours.
o Apm maintenance: Here you configure the Apm maintenance period.

This setting tells the SchedSvc to perform maintenance on the LD_LDAP_TARGETS table, and also to
perform maintenance for stale tasks by setting the task status to Failed or DonePartial based on
whether or not the task has targets that have completed status.
Software Distribution Download Hierarchy

At the heart of Software Distribution is ingenious technology that delivers the software consuming the least
amount of bandwidth possible. This is accomplished by a hierarchical download structure, including ability to
leverage a Management Suite unique delivery method known as Self-Organizing Multicast.
All delivery methods contain a configurable way to manage download to devices, so that minimal bandwidth is
consumed. Delivery follows a specific order to find, download, and install, the software distribution package.

 First, the agent will check in the device’s local sdmcache directory (C:\Program Files\LANDesk\
LDClient\sdmcache) for the package.
 Second, if the package is not in its local directory, the agent broadcasts to other agents looking for peers
who have the package.
NOTE: If the device has a Distribution and Patch Agent Setting with Use multicast enabled, it will wait for
a short, configurable, wait time and then receive the distribution package as a broadcast from a local
device, which broadcasts to all devices on the same subnet. Each device on the subnet will receive the
package, at the same time, from the broadcast. (For more information please see the Self-Organizing
Multicast section.)
 Third, if a peer does not have the package, the agent seeks to see if it exists on the closest Preferred
Server.
 Fourth, if none of the above sources have the package, the agent reads the Software Distribution Package
to determine the path to the package and downloads from there.

This download hierarchy assures that the minimum amount of bandwidth will be consumed to deliver and
install the software applications placed via Software Distribution. Consider the fact that once one managed
device downloads the software, all other devices on that subnet can get the software from a peer rather than
through a remote WAN link, as long as that device, or any other device, has the software package in its local
sdmcache directory. (The default setting has managed devices hold the software package in its local
sdmcache directory for 48 hours.)
If you want to change or omit any of these download options, you can set the option in the Distribution and
Patch Agent setting. Simply deselect any Preferred server / Peer download options you wish to omit.

Software Distribution Push
A push delivery is a method of immediately starting the download and installation of software to devices that
are able to be contacted by the Core Server. The steps taken to enact the push, initiate the download, and
launch the installation of software are as follows:
1. The LANDESK Scheduler Service (SchedSvc.exe), on the Core Server, reads the scheduled tasks
that are stored in the database. When the task is created the .xml file (CP.#.RunNow.xml) is created on
the core server (# is the task number) in the Program
Files\LANDesk\ManagmentSuite\landesk\files\ClientPolicies directory.
The task is launched and the scheduler finds a task is due and launches the Task Handler Proxy.
2. The Task Handler Proxy (TaskHandlerProxy.exe), on the Core Server, gathers information about the
specific task from the database and sends the information to the Policy Task Handler.
3. The Policy Task Handler (PolicyTaskHandler.exe), on the Core Server, sorts target devices in each
task by IP Address. It matches DeviceID and MAC Address of target devices, and discovers DNS
information (if configured to do so), and sends the command to launch PolicySync on each target
device using the TaskID as a parameter.
4. On the targeted devices, the Software Distribution Client (SDClient.exe) receives the .XML file and
starts the action to download and install the software.
Software Distribution Policy

With business becoming more mobile, the need to deliver software to occasionally connected devices has
risen. To answer this need, Management Suite offers a Policy method which enables a pull of software initiated
from the managed device when it is connected to the internet (via the Cloud Appliance) or the corporate
network via a Virtual Private Network (VPN). The Policy delivery occurs as follows:

1. The LANDESK Scheduler Service (SchedSvc.exe), on the Core Server, reads the scheduled tasks
that are stored in the database. When the task is created the .xml file (CP.#.xml) is created on the core
server (# is the task number) in the Program
Files\LANDesk\ManagmentSuite\landesk\files\ClientPolicies directory.
The task is launched and the scheduler finds a task is due and launches the Task Handler Proxy.
2. The Task Handler Proxy (TaskHandlerProxy.exe), on the Core Server, gathers information about the
specific task from the database and sends the information to the Policy Task Handler.
3. The Policy Task Handler (PolicyTaskHandler.exe), on the Core Server, sorts target devices in each
task by IP Address. It matches DeviceID and MAC Address of target devices, and discovers DNS
information (if configured to do so). When PolicySync (on each target device) asks if pending tasks
exist, Policy Task Handler passes the TaskID as a response.
4. On the targeted devices, policy sync (PolicySync.exe) sees that a task has been made available. It
checks whether the policy is automatic, recommended, or optional.
5. For Automatic policies the software distribution client (SDClient.exe) launches the task, and the
download and installation occurs.
6. For Optional and Recommended policies, the software distribution client (SDClient.exe) stores the
parameters on the managed device. The task is then made available in the Portal Manager of the
managed device.

Preferred Servers
The size of software applications ranges all the way from tiny apps of a few kilobytes to huge installations of
multiple Gigabytes. Software Distribution provides a central resource for distributing software, but with slow
WAN links crossing geographic regions, it is built to leverage local copies of the software applications stored
on Preferred Servers.
Preferred Servers are shares where software applications are stored for delivery to managed devices from a
local source. As was pointed out previously, in the Software Distribution Download Hierarchy, the Preferred
Server is sought out, prior to going to the central source for obtaining software for installation.
Preferred Servers can receive updated Distribution Packages from multiple mediums, but Management Suite
customers have asked Ivanti to leverage the bandwidth throttling ability built into Management Suite to update
the Preferred Server. Ivanti has answered with Content Replication.
Content Replication schedules regular updates of:

 Patches to be deployed
 Operating System Images
all of which can be deployed, utilized, and leveraged, by Management Suite.
Content Replication
To use Content Replication Management Suite implements the following three roles. Namely:
 Preferred servers (targets) – local shares in various geographies that offer to managed devices its
resources (Distribution Packages, Patches, OS Images)
 Sources – shares containing original resources (Distribution Packages, Patches, OS Images)

 Replicators – Windows Devices with the Management Suite Agent, including Software Distribution, which
downloads resources from sources to the local sdmcache directory, and then copies those resources to
targets.
(Note: Multiple Sources can serve as resource to one or multiple Replicators. Also, Replicators can deliver
resources to one or multiple targets. Both Sources and Replicators can be set as a one-to-one or a one-to-
many resource.)
The steps are as follows:
1. Configure a Source (UNC share or Web share) to be replicated to Preferred Server (targets).
2. Configure a Preferred Server (target) for each subnet where a local source is desired.
3. Configure a Replicator to copy/update information from source(s) to target(s). This schedules the
replication updates.
Self-Organizing Multicast™
Deploying software packages, some of which are very large, can easily overwhelm the network. To effectively
address this issue Management Suite offers its patented Self-Organizing Multicast™ solution to address LAN
and WAN bandwidth consumption, and speed of deployment. To see an animation describing the process, go
to: https://community.ivanti.com/support/docs/DOC-34266.
Self-Organizing Multicast technology enables faster software distribution without expensive and time
consuming router reconfigurations. Multicast does NOT need to be enabled on the routers. Its revolutionary
self-organizing feature relieves the administrative burden from network setup and centralized overhead.
Self-Organizing Multicast greatly speeds up imaging over LANs, WANs, and especially over slow WAN links,
by transferring the software files only ONCE to each subnet across a LAN or WAN and allowing a self-aware
process to assign a device on each subnet to broadcast the files to other recipient devices.
The steps of Self-Organizing Multicast are as follows:
1. A software distribution task is scheduled and started.

2. Each targeted device receives the task and broadcasts to its subnet, asking if there is a designated
Multicast Domain Representative.
a. The first device to ask does not receive a message saying that there is yet a Multicast Domain
Representative. It assumes that role and begins downloading the software package from the nearest
source (whether that is a peer, a preferred server, or the original source) immediately. (To be a
Multicast Domain Representative the device must be running the LANDESK Targeted Multicast
service, tmcsvc.exe, which is installed on each Windows device, by default, as part of the
Management Suite Agent).
b. The other devices designated to receive the software package on that subnet broadcast ask if there is
yet a Multicast Domain Representative. They receive a positive response from the Multicast Domain
Representative. They go into listening mode, waiting for the Multicast Domain Representative to start
broadcasting.
3. After the time designated in the Use Multicast option passes (1 minute by default), the Multicast Domain
Representative, which has been downloading the software, begins to broadcast the software to all
recipients on port 0, the Multicast port. (Hence the name Self-Organizing Multicast.)
4. The Multicast Domain Representative continues to download and broadcast until all the software file-by-file
has been downloaded and broadcast. For larger files or packages, the Multicast Domain Representative
may be both downloading and broadcasting at the same time.

The bandwidth savings for such a process increases as the number of targets per subnet increases, since the
package is downloaded once, and broadcast once. Without the process each device would have to download
the package singly.
Self-Organizing Multicast Behavior

Self-Organizing Multicast sends the full contents of a file. The bandwidth setting affects the speed that the
blocks of data are transferred. (A block of data is the Ethernet frame minus IDP and UDP overhead, which is
about 14 to 16 bytes.) At 100% speed, all blocks would be transferred at full speed until each file in the
software distribution package is sent. At 99% speed, 400 blocks would be sent, and a sleep time would be
invoked. The length of sleep time may vary, depending on the time it would take to send the 400 blocks of
data. At 1% speed, 10 blocks would be transferred and a sleep time would be invoked (the sleep time would
vary based upon the time it would take to send 10 blocks of data.) All other bandwidth settings are somewhere
between the 99% and 1% already described.
After each file is sent, a response to resend requests is executed. This gives to managed devices missing data
(if the missed data is less than 10% of the file or image). If a managed device misses more that 10% of the file,
it receives the missing data using peer recovery. In peer recovery an address to a local machine with the
needed data is provided. Using this information the device requesting the data can contact the local peer and
receive the missing data.
Beginning with Management Suite version 2016 additional security has been added. All clients who participate
in self-election provide their public keys to all devices which will receive its broadcasts. Each device assures
the public key matches its public key before receiving the broadcast packets.
Multicast Settings (Pre-9.6 Agents Only)

For pre-9.6 Management Suite Agents, you can enable a task to use Targeted Multicast by selection in a Push,
Policy-supported Push, or Multicast (cache only) delivery method, on the Network usage page.
(If the Use multicast to deploy files option is chosen the Preferred server / Peer download options do not
apply, and therefore become unavailable for selection.)

 You can throttle bandwidth consumption on the Bandwidth usage page of a Push, Policy-supported Push,
or Multicast (cache only) delivery method.
 Settings that are on the Multicast domains page are as follows:
 Multicast domain options are pre-9.6 options.

 Wake on LAN configures whether the domain representative will send the Wake-on-LAN magic packet
and wait a set number of seconds before broadcasting.

Other multicast settings are set on the Multicast limits page of a Push, Policy-supported Push, or Multicast
(cache only) delivery method.
 Maximum number of multicast domain representatives working simultaneously: Sets how many
Multicast Domain Representatives can download simultaneously. For larger software packages you want a
smaller number, whereas for smaller software packages you want a higher number.
 Maximum number of device that failed multicast to process simultaneously: Sets how many target
devices can fail the multicast task before the Multicast Domain Representative will stop broadcasting and
report failure.
 Number of days files stay in the device’s cache: Sets how long the non-Multicast Domain
Representative target devices will keep the software packages in their sdmcache directory before deleting
them. (Availability in this directory is to provide peer-to-peer download in the future.)
 Number of days files stay in cache on multicast domain representatives: Sets how long the Multicast
Domain Representatives will keep the software packages in their sdmcache directory before deleting them.
(Availability in this directory is to provide peer-to-peer download in the future.)
You can also customize Targeted Multicast options in the Multicast tab of Configure > Services > Multicast.

 Use Multicast domain representative: Uses the list of multicast domain representatives stored in the
network view’s Configuration > Multicast domain representatives (Pre 9.6 only) group.
 Use cached file: Queries each multicast domain to find out who might already have the file, therefore
bypassing the need for the Multicast Domain Representative to download the file.
o Use cached file before preferred domain representative: Changes the order of discovery to make
Use cached file the first option attempted.
 Use broadcast: Sends a subnet-directed broadcast to find any device in that subnet that could be
multicast domain representative
 Log discard period: Specifies the number of days that entries in the log will be retained before being
deleted.
Backup / Restore Software Distribution Packages

The file package.porter.exe, located in the C:\Program Files\LANDesk\ManagementSuite folder is used to
export Software Distribution Package definitions from the database. This application will export all PUBLIC
Software distribution packages to an XML file specified at runtime. This does NOT include the actual
distribution package file, just the information regarding the packages that is stored in the database. The
following is a command line utility syntax example:
• Package.porter.exe export /file=c:\backup\packages.xml
To import use the following syntax:
• Package.porter.exe import /file=c:\backup\packages.xml
There is an optional command line switch, /replace, to overwrite any existing Software Distribution packages
with the same name.
Both of these utilities will export only the PUBLIC Distribution Packages and Delivery Methods from the
Console.
UNC Shares
For UNC distributions to work correctly, configure a Preferred Server.
You can download “How to Configure a Preferred Package Server” at:
You can download “How to debug why my preferred server config isn’t being used (Preferred server doesn’t
work)” at:
The Preferred Server configuration includes entering credentials of a service account, which provides read
rights to the software repository. When sdclient.exe downloads the software Distribution Package, it uses the
rights configured in the Preferred Server, without the end-user knowing the account or password granting
access rights. The installation of the software uses settings configured in the Distribution Package on the
Accounts page. The LocalSystem account setting uses a locally running service for administration rights.
The Current user’s account setting uses the currently logged on user’s rights and location for the installation.

Web Shares
To distribute software from a Web share, the Web share must be HTTP 1.1 compliant. The compliance
enables byte level restart and bandwidth checking during downloads. With HTTP being the operative protocol,
port 80 must open on the network between the source and the managed devices.
Software Distribution Package Types

A Software Distribution Package is a definition or collection of information about a package that is configured
by an administrator and stored in the core database. Included in the information is the location of the software
distribution package as well as other configured options that describe how the package behaves when it gets
distributed to and installed on the managed device.
Options in the Software Distribution Packages include:

 Options to install or uninstall the package
 Run time command-line parameters
 Additional files required by the package
 Dependencies and prerequisites required
 The option to specify the account the package will use during install
 The option to associate the package with another package that is designed to uninstall the package
 The ability to assign return codes
 The ability to assign metadata such as: estimated download/install times, categories, a logo, screenshots,
or tags.
To create a software distribution package, the files that it references must be copied to the distribution server.
For tips, tricks, and settings, visit http://itninja.com for application specific help.
Distribution Packages Menu

Additions to the distribution packages tool have led to an enhanced presentation of options. The first, and most
obvious presentation change is the distribution packages menu.
Software distribution supports the distribution of the following package types:

 Bundle:
Package bundles add the ability to deploy any number of software distribution packages, as a group, in
succession. Simply create the bundle and schedule it to deploy.
It is possible to create bundles within bundles, but you can only adjust the installation order for items at the
selected bundle's root level. Each bundle and sub-bundle has its own installation order.
In the bundle properties you can specify that the bundle cannot be scheduled. This is useful for bundle
organization and helps prevent accidental deployments of those organizational bundles. For example, you
could have a "Microsoft" bundle that contains all of the Microsoft applications you support.
Inter-package actions add control options to each distribution package within a bundle.
o Continue on install failure: If this action is included, the distribution packages following this package
within the bundle will continue to be deployed if the distribution package fails to successfully install. If this
action is NOT included, the distribution packages following this package within the bundle will NOT be
deployed if this distribution package fails to successfully install.
o Reboot: Add this action to reboot the managed devices installing the distribution package. There will be a
30 second delay on the managed device before the reboot occurs. When the reboot is complete, the next
distribution package in the bundle will install.
Note
.BAT files often launch the next package without completing. It is advised that you
do not include .bat files in a package bundle unless it is the last package. Using
provisioning templates to install software has no such limitation with .bat files.
To create a bundle
1. Click Tools or Toolbox > Distribution > Distribution packages.
2. In the Distribution packages tree, right-click a category or a bundle in a category, and click New
package bundle.
3. Edit the bundle name and click enter.
4. Drag packages and other bundles onto the bundle you created to add them.
To change the package order in a bundle

1. Right-click the bundle you want and click Properties.
2. On the Bundle package settings page, use the Up and Down buttons to reorder the root-level items
in that bundle.

To add an inter-package action
1. Right-click the bundle you want and click Properties.
2. On the Bundle package settings page, move to the right pane the desired inter-package action.
 Linux (.rpm):
Linux packages are in Linux Red Hat Package Manager (RPM) format. Linux packages must be accessed
from a web share. (Assure that directory browsing is enabled on the Web share.) To distribute software to
a Linux device, you must have Administrator rights. Linux packages can detect dependencies and warn the
user about missing libraries.
 Macintosh:
Macintosh supports numerous software package formats such as, .dmg, .pkg, .mpkg, .sit, .sitx, .zip, .tar,
.gz, .sea, .app, .sh, .hqx or Automator/workflow packages. These install packages will need to
decompress before installation. The Management Suite Agent will initiate the decompression and install the
package. (All OS X versions include a decompression utility as a part of the OS.)
 Mobile:
Mobile applications are available for both Android and iOS (version 7.0 and later). These applications can
be made available via the App store or via a Manifest URL. The packages must be a free version only.
o Android: Packages for Android managed devices.
o iOS: Packages for iPhone managed devices.
 Universal: Offers the following options:

o Link: Links are shortcuts to distribution packages, executables, or a URL. Links can appear in the
LANDESK Fuse portal, the Launchpad (on the LANDESK portal manager), the desktop, or in the Start
menu. This package type replaces the LaunchPad link manager tool which was available in previous
versions.
o Provisioning: Provisioning packages are those which were created in the OS provisioning tool and
can be included as actions in OS provisioning templates.
o Streamed Document: Streamed documents are generally used with package bundles to provide
users with additional instructions or information. They
can be viewed on managed devices through the LANDESK portal manager. A streamed document can
he hosted on either a UNC or HTTP share that can be accessed by managed devices. The streamed
document file extension must have an application associated with it that can display that document
type. Streamed documents are not cached locally.
 Windows: Offers the following options:

o Actions: These are carried out by PowerShell, and include the following:
 Copy file
 Rename file
 Delete file
 Move file
 Create directory
 Delete directory
 Stop service

 Start service
 Restart service
 Unzip file
 Add registry entry
 Delete registry entry
 Update registry entry
 Connect UNC share
 Disconnect UNC share
 Launch an executable
 Wait
 Standard popup window
 Custom (create a custom PowerShell Windows action)
o Batch File (.bat):

These are packages whose commands are placed in a batch file. They can support pre-steps and
automated installation parameters referenced in the .bat along with command file parameters. This file
type of installation can support sophisticated or customized installations, such as detecting the
Operating System receiving the installation, and referencing commands based on the result. Batch
installation can also support variables and command logic built into the .bat file. Any batch file can be
called up whether it is for installation or other purposes.
o Executable File (.exe):

These are packages whose manufacturer has provided prepackaged EXE installation files. These files
can often include command-line switches specific to the application. These files have the following
requirements:
 The executable must not exist before the installation is complete
 The executable must return zero (0) for a successful installation.
There are times when an executable is simply a wrapper for an .msi file. If such is the case, extract the
.msi file and use the MSI Distribution Package for installation.
o Microsoft Installer File (.msi):

These are packages in the Windows Installer format. Many software companies now include
prepackaged MSI installation files including files with other support files needed for the installation.
Software Distribution supports MSI installation with full status reporting and MSI package recognition
by it GUID. MSI installations can be customized to use .mst transform files.
Transform files are answer files that customize how MSI packages are installed. They also
facilitate a silent install where otherwise the installation would not be silent as it would require
user input to complete. The syntax on the command line to utilize an .mst file is:
TRANSFORMS=[FILENAME].MST (all in UPPER CASE).
The command line also uses option parameters (called switches) and property reference parameters.
All switches, property references, and transforms, can be entered in the Command Line field of an MSI
Distribution Package’s Install/Uninstall option. To see a list of MSIExec switches go to a command
prompt and use the msiexec.exe /? option, or get additional information from the document

Command-Line Switches for the Microsoft Windows Installer Tool at:
http://support.microsoft.com/kb/227091/en-us.
Additionally the document How to Use Property Reference Command-Line Parameter with
Msiexec.exe is available at http://support.microsoft.com/kb/230781/en-us.
Options adding versatility to using MSI Distribution Packages include:

 The Option to Install or Uninstall the application
 MSIEXEC parameter providing
- Status reporting
- .MST (Transforms) and .MSP (Patching) ability for installation
- Property reference parameters
- Switch support
 Auto detect for additional files if set in the MSI setting
 Detection automatic checked because of GUID association
 Command-line check feature
o PowerShell:
Microsoft describes PowerShell as “a task-based command-line shell and scripting language designed
especially for system administration. Built on the .NET Framework, Windows PowerShell helps IT
professionals and power users control and automate the administration of the Windows operating
system and applications that run on Windows.” (http://technet.microsoft.com/en-
us/library/bb978526.aspx.)
One of the features PowerShell adds is ability to use built-in commands called cmdlets. These let you
utilize the command line to manage enterprise computers. PowerShell providers add ability to access
data stores, like registry and certificate stores for easy file system access. It also has a parser as well
as a full scripting language.
o Script Host:
Microsoft offers an alternative to batch files. Windows Script Host (WSH) Packages often automate
tasks traditionally done in batch files (i.e. copying files, mapping drives, or modifying registry keys).
WSH files are most commonly used with Jscript (.JS) and VBScript (.VBS). One major advantage of
the WSH packages over a .bat package is they allow the user to combine multiple languages into a
single file by using the language independent file extension (WSF). These packages are often created
in notepad, HTML editor, Microsoft Visual C++ or Visual InterDev.
o Store Application:
Store Application packages start package installation on the device. Packages can be downloaded
from either a web path or a file share path.
o SWD:
Software Distribution (SWD) packages are those which were built with the legacy Management Suite
Enhanced Package Builder. Although the Enhanced Package Builder is no longer shipped with
Management Suite, Ivanti continues to support the distribution of files created with it. Files that have
been created with the legacy builder will have a .exe extension, but will be uniquely identified as SWD
packages.

o Virtualized Application:
Software Distribution supports virtualized applications for both being installed and uninstalled. When
run, virtualized applications run in an isolated environment without making changes to the Windows
installation they are run on. Virtualized applications run on locked-down devices without requiring
additional privileges.
The Distribution and Patch Agent setting sets the default path to install the virtualized application.
Creating Management Suite Distribution Packages

When creating Management Suite distribution packages, a good practice is to create and test the packages
from My Packages and when they are tested, and deemed ready to use in a production environment, move
them to Public packages.

Metadata
There are Metadata options, which affect how a package looks inside the portal (LANDESK portal manager).

Metadata options include:
 Additional settings: Options in Metadata > Additional settings include:

o Application vendor: Here you can enter the vendor name.
o Estimated download time: Here you can enter how long you estimate the download will take. This is
to set an expectation with the end user downloading the software via the portal.
o Estimated install time: Here you can enter how long you estimate the installation will take. This is to
set an expectation with the end user installing the package via the portal.
o Reboot expected: Selecting this checkbox inform the end user installing the package via the portal if
they will need to reboot after the package installs.

 Categories: Options in Metadata > Categories are used for filter options in the LANDESK Portal Manager.
In order to select a category, it must first be created. To create a category, go to the Distribution packages
toolbar, click Configure settings (The Default package settings windows appears, then click to select the
Categories page.)
o Item: Type the name of the category you wish to assign to distribution packages.
o List of items: List of categories added for selection for distribution packages.

You may add an image which can show in the end user software catalog.
o Add image: In the categories page you can add a corporate logo to display when deploying a
package. For best results, use PNG image types 320 x 200 pixels in dimension.
o Clear image: To remove an image from the categories page.
 Tags: Options in Metadata > Tags are used for filter options in the LANDESK Portal Manager. In order to
select a tag, it must first be created. To create a tag, go to the Distribution packages toolbar, click
Configure settings (The Default package settings windows appears, then click to select the Tags page.)
Tags created in the default package settings are available for selection when creating distribution
packages.

 Tags: Package tags are used for a filter option in the Portal Manager. Tags are keywords that you can
assign to packages.
Once tags have been created, select the Enable tags box and select the tags you want assigned to the
package. You can assign multiple tags to a package.
Creating Software Distribution Packages

There are many options when creating a Software Distribution package. Some or all of the options are
available, based upon the type of package.

 Package information: Offers the following fields:
o Name: This field contains the name that appears in the Distribution packages and Delivery methods
dialogs when scheduling software distribution. If delivery is configured so, the recipient will see the
name in the LANDESK Portal Manager, or Desktop Manager, as well as the final status.
o Description: This field contains the description that appears in the Distribution packages and Delivery
methods dialogs when scheduling software distribution. If delivery is configured so, the recipient will
see the description in the LANDESK Portal Manager or Desktop Manager.
o Primary file: This field contains the file name and location for the main file in this package.
 Install/Uninstall options: Offers the ability to install MSI packages, SWD packages, Linux packages, and
Virtualized Application packages. For MSI packages there are additional MSI options.
The Enter command line option give ability to add command line options applicable to the installation of the
distribution package.
 Architecture options: The selected architecture field lets you select from
o Not applicable: Packages will run in 32-bit mode, regardless of the OS architecture.
o 32-bit: Only run the package on 32-bit operating systems.
o 64-bit: Only run the package on 64-bit operating systems.
o System architecture: Automatically detect and execute the package based on the OS architecture
(e.g. executes the package in 64-bit mode on 64-bit operating systems.)
Normally, 32-bit applications:

o Access registry in HKEY_LOCAL_MACHINE\SOFTWARE.
o Run programs found in C:\Windows\System32.
Normally, 64-bit applications:

o Access registry in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node.

o Run programs found in C:\Windows\SysWOW64.
If you select System architecture, 32-bit applications will direct to the appropriate locations listed above.
However, 64-bit applications will:
o Access registry in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.
o Run programs found in C:\Windows\SysWOW64. This includes cmd.exe, cscript.exe, wscript.exe and
others.
For more information from Microsoft about running 32-bit applications in a 64-bit environment, see this
MSDN page:
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx
 Client queue options: By default, client queuing is enabled. If another install process is running, the
software distribution task will wait until the install completes, and then run the software distribution task.
To disable client queuing select the Disable client queuing for this package checkbox. In that case if
another install process is running, the task will fail and report status that another installation is occurring.
 Additional files: Add all additional files required for installation. If there is an .MST or .MSP file to
accompany an MSI install, these files should be included here. All files which a .BAT file might call or
include should be added here.
For .MSI packages an [Auto detect] button is made available. This button will parse the .MSI file and
include files referenced by the .MSI file. (If the person who packaged the .MSI file has not correctly
referenced the additional files, the auto detect will fail to add additional files.)
 Dependent packages: Dependent packages are packages that must already be installed on the device in
order for the package you are configuring to be installed. If the dependent package is not on the device,
dependent packages are first installed prior to installing the scheduled package.
MSI and SWD package types are detected automatically through appropriate registry keys on the device.
For other package types, the package detection method must be defined.
 Prerequisites: Offers ability to specify a prerequisite query or file/program return code to allow a software
distribution package to be deployed.
The query option offers the ability to create and apply a query, so targeted devices which do NOT satisfy
the query will NOT receive the package. The failed scheduled task will reflect the prerequisites were not
met. (Two popular uses are to query for a specific Operating System or a specified amount of available
hard disk space.)
The additional file or program return code option is to run a file or program on a device and return an error-
level code. A non-zero code prevents the package from installing. The details will be in the distribution
task’s log file.

o Choose a query: Select from a list of available queries what prerequisites must be met for the
package installation to occur.
o Create query: Allow you to create a query which could then be selected.
o Run additional file: Select to run an additional file prior to installation.
o Choose an additional file: Enter the file to run prior to installation, to run an error-level return to see
whether the package installation will occur.
o Enter command line or select options above and edit command line for MSI package: If the file
you specify to run needs a command line, enter it here.
 Detection: The detection option is available to have you define what files and/or registry entries to locate to
determine if this software distribution package has been installed. This option is to be used in conjunction
with dependent packages.
This option is only available for Executable packages, Batch File packages, Virtualized Application
packages, Windows Script Host packages, and PowerShell packages. (The other package types do not
require this option for they are already able to be detected as installed.)
There are multiple options for defining how to detect files and/or registry entries.
o Detect by: Gives the following options for detection:

 File exists: Allows a file path and file name to be entered in the File path field. An option is
presented to search for the file name recursively. This option looks for just a file name. The
version, size, or checksum, will NOT matter.
 File version: Allows a file path and file name to be entered in the File path field, as well as a
minimum file version. An option is presented to search for the file name recursively. If the file
name is found AND the version is the specified version, or later, the criterion is met.

 File size and/or checksum: Allows a file path and file name to be entered in the File path field, as
well as fields to enter a file size (in bytes), and/or checksum. An option is presented to search for
the file name recursively. If the file name with the specified size and/or checksum specified is
found, the criterion is met.
 File date: Allows a file path and file name to be entered in the File path field, as well as a
minimum file date. An option is presented to search for the file name recursively. If the file name is
found AND the file is the specified date, or later, the criterion is met.
 Registry key exists: Allows a registry key in HKEY_LOCAL_MACHINE to be designated. If the
specified registry key exists, the criterion is met.
 Registry value exists: Allows a registry key in HKEY_LOCAL_MACHINE, and a value name to
be designated. If the specified registry key AND specified value exists, the criterion is met.
 Matching registry value: Allows a registry key in HKEY_LOCAL_MACHINE, and a value name,
and data, to be designated. If the specified registry key AND specified value exists, AND the value
matches the data specified, the criterion is met.
 Accounts: This option places one of three accounts to use to distribute the software package.
o LocalSystem account: Will install as the LocalSystem device account, effectively granting installation
with Administrative rights.
o Current user’s account: Will install as the User logged in at the time the distribution occurs. If a User
is not logged in, the distribution will fail.
o Run as specified user: Will install as the user specified. Selecting this option requires the input of the
domain\user name and password.
 Timeout Settings: Selecting this option places a time limit (in hours) for allowing how long a package has
to install. If the package has not completed installation within the set time, SDCLIENT.EXE will exit, and the
package will be reported as failed. By default, this option is NOT selected.
 Uninstall Association: This option is ONLY available with a Policy distribution. Selecting this will
automatically uninstall the selected software package from the device when the machine or user is
removed from the target list or query in the scheduled task. To select an uninstall package, click the
desired uninstall package in the available distribution packages field, and click [Set].

 Assign return codes: This opens a window to act upon return code templates. Here you can Modify, or
Assign return code templates. Templates that appear in the list to be acted upon are created by clicking the
Return code template manager icon on the Distribution packages toolbar.
This gives the ability to add a return code and corresponding message and designate a success or failed
status. If a distribution package succeeds, but the task reports as failed, adding a return code gives the
ability to report as successful.
 SWD package options: This option is available for SWD packages ONLY. It gives control to how install a
package if the package has already been installed. It also offers a package feature that allows a
background screen to be displayed during package installation.
o Heal (repair) the package: This option will have the package check file checksums on the target
device, and overwrite only those files whose checksum is different than the files in the SWD package.
o Perform a full reinstall of the package: This option will fully install the package over what already
exists on the target device.
o When feedback is enabled, override the above setting and allow the user to decide: This option
places the decision to fully install, or repair the package, on the end-user IF the delivery method
selected makes provision for this option.
o When feedback is enabled, display the background screen: This option enables the feature to
show a background screen during the installation, giving the end-user feedback that the installation is
in process.
Toolbar icons in the Distribution packages tool
The icons available in the toolbar in the Distribution packages tool include:
 New Distribution package: To build new distribution packages.

 Delete: To delete distribution packages.
 Copy: To use for copy/paste functionality.
 Properties: To show and select properties of a distribution package.
 Relationships: To view software packages which are assigned a relationship (if included in a package
bundle).

 Refresh: To refresh the view in distribution packages.
 Reset package hash(es): To reset a package hash (after a distribution package has been edited).
Due to package availability from peers and preferred server sources, the files are verified prior to
installation. The files are verified by comparing the MD5 hash generated at the Core Server and stored with
the package. When a distribution package is scheduled, the MD5 hash associated with the primary file and
additional files, is a part of the task. SDClient compares the hash in the scheduled task with the files. If the
hash on the files does not match the hash on the Core Server, the download will fail.
 Create scheduled task(s): This creates a Scheduled Task of the selected distribution package using the
default delivery method. The Scheduled Task tool will have focus, target device(s) can be added, and then
the scheduled task can be started.
 Return code template manager: This opens a window to act upon return code templates. Here you can
Add, Modify, Delete, Import, Export, or Set Default return code templates.
This gives the ability to add a return code and corresponding message and designate a success or failed
status. If a distribution package succeeds, but the task reports as failed, adding a return code gives the
ability to report as successful.
 Bulk package credentials update: Each software distribution package has an Accounts properties page,
used to assign which user account to use to distribute the package. Options include:
o LocalSystem account: This is the default. Rights are inherited by using access of a service (namely
the LANDESK Remote Control Service).
o Current user’s account: Uses the account of the user currently logged on.
o Run as a specified user: Uses the account designated along with the corresponding set password.
The Bulk Package Credentials Update Tool is used to assign the accounts to be used to install software
packages for multiple packages. Open the tool, designate the Domain\User, the Password, select the
packages to assign and click the [Update] button. This will assign the account for all selected packages.
 Configure settings: Gives access to set:
o Default package location: Gives access to a field where you can set the default location that will be
used when creating distribution packages.
o PowerShell security: Gives access to select whether to require PowerShell scripts to be signed.
o Categories: Gives access to where categories can be created. These categories can be used to filter
the view in the portal manager.
o Tags: Give access to where tags can be created. These tags can be used to filter the view in the portal
manger, or for use in rollout projects.
 Volume Purchase Program Configuration: Gives access to add tokens to the Apple Volume Purchase
Program.
o Add VPP Token: Gives access to put a token alias, and a browse to a file downloaded from the Apple
VPP site. This will then track licenses to an application (by Application, Application Id, Target device,
Total licenses, and Available licenses).
o Delete: Gives access to delete a token on the list.
 Help: Opens help files for distribution package which are context sensitive and searchable.
Agent Settings
Agent settings put into place how managed devices perform tasks. The Distribution and Patch agent settings
set how Software Distribution and Patch Management tasks are performed. These agent settings can be
initially deployed, or updated and assigned via a scheduled task. The portions of the Distribution and Patch
agent setting which affects Software Distribution are:

 Network settings: Here, selections are made for the following items:
o Preferred server / Peer download options: Select checkboxes to include whether or not to install
software using the following hierarchy:
 Attempt peer download (download files from other clients on the same subnet)
 Attempt preferred server (automatically redirect to the closest preferred server)
 Allow source (download from original location if files were not found in other locations)
 Use multicast (and set the automatic delay for the Multicast Domain Representative). For more
information see Self-Organizing Multicast.
o Bandwidth used from core or preferred server (WAN): Set the percentage of available bandwidth to
use when downloading from the source or preferred server.
o Bandwidth used peer-to-peer (Local): Set the percentage of available bandwidth to use when
downloading from a peer.
o Send detailed task status: Select whether to send detailed task status to the scheduler while
performing the task.

 Policy sync schedule: Settings here add to the local scheduler of the managed device when to run
PolicySync.exe to check for tasks and policies. Options include:
o When user logs in: Whether to run PolicySync.exe upon login (after a random delay)
o When IP address changes: Whether to run PolicySync.exe after an IP address change
o Use recurring schedule: Whether to run PolicySync.exe on a recurring schedule
 Notification: Here, you set the following options:

o Notification options to begin downloading: Settings for beginning download include:
 Automatically begin downloading: Begins downloading the package prior to install, silently; with
no notification to the end user on the managed device.
 Notify user before downloading: The following window appears on the managed device if you
select Notify user before downloading.

o Notification options to begin installing/removing: Settings for beginning the install or removal
include:
 Automatically begin installing/removing
 Notify user before installing/removing
 User cannot defer or cancel action
 User can only defer action
 User can defer or cancel action
 Only notify user if processes must be stopped
 Defer until machine is locked (deprecated – use maintenance window)
 If deferring until lock a configurable wait time is added (5 minutes default)
 Defer until user is logged off (deprecated – use maintenance window)
 If deferring until logoff a configurable wait time is added (5 minutes default)
If you select Notify user before installing/removing the following window appears:

o Kill processes that need to be stopped before starting the update: Select the checkbox to set
whether to use this option.
o Prevent those same processes from running during the update
o Show progress: Select how to show progress from the following options:
 Never
 Only when installing/removing
 Always (when scanning and installing/removing)
(If you select one of the bottom two options, to show progress, the following appears on the task
bar when downloading the software package.)
o No response timeout options: Select whether to . . .

 Wait for user response before repair, install or uninstall OR
 After timeout, automatically: to start install, cancel install, or defer install until machine locked

 User message: Set the message to appear to end users to appear to end users when distributing software
(if notification before downloading is set to Notify user before downloading; or if notification before
install/remove options are set to either Notify user before installing/removing, or Only notify user if
processes must be stopped).
 Distribution-only settings: Sets the following options on the managed device:

o Feedback: Select whether to use the following options (if ‘Show progress’ is selected on the
‘Notification’ panel):

 Display full package interface
 Show successful or failed status to end user: If you show successful or failed status the
following window appears. Note: the window is set to always on top.
o Defer until next logon: Select to defer the install/removal until the next logon.
o Defer for a specific amount of time: If set to allow the user to defer, this sets how long that deferral
will be.
o Limit number of user deferrals: If set to allow the user to defer, this sets how many times the user
can defer.
o Select the location to store virtualized application to the Client Destination: Set the destination
on the managed device. The path accepts environment variables from the local machine.
o Enable LDAP group targeting: Select whether to enable LDAP group targeting.
o Enable LDAP resolution via CSA: Select whether to enable LDAP resolution if the device is communicating
via the Cloud Services Appliance.
 Offline: Set how to manage the install/removal if the managed device cannot contact the core server.
These options address the business issue of choosing how to proceed if laptops are remote and not
connected at the normal place of business. Options include:
o Wait until the device can contact the managed core server
o Install package(s) offline
 Logged off user options: Select one of three options as to how to proceed with the distribution package
when the user is logged off. Options include:
o Continue installation
o Fail installation

o Run at next login
 Download options: Select one of two options as to download the distribution package. Options include:
o Run from source (execute on share): This is bandwidth intensive as the package will run from the
share and will not download using a bandwidth effective method. This option should only be chosen if
the software requires this setting.
o Download and execute: This is bandwidth effective as the package will obtain the software from the
closest source, copy to its local sdmcache directory, and then execute the install/removal.

Scheduling the Distribution Package
When scheduling the distribution package by clicking the Create software distribution task icon on the
Scheduled tasks tool various settings are offered, including:
 Overview: Shows the package Name, Owner, Scope by user, Distribution package, Delivery method,
Currently selected targets, and Scheduled time.
 Distribution Package: Shows the order in which packages in the scheduled task will be deployed.
 Targets: Grants access to view, add, and delete, items to the scheduled task.

o Add: Grants access to add items of any of the targeted types. Click to select the target type, then click
the [Add] button, and add items.
o Remove: Grants access to delete targeted items. Click the select box to the left of the item, then click
the [Remove] button.

 Task settings: Allows selection of different settings including: Task type, Action type, Frequency,
Additional Push options, and Download options.
o Task type: Select one of these three options:

 Policy-supported push: The combined push and policy options. The task is sent to every
targeted device. Those devices which are on and connected run the task. The devices which are
not connected or are powered off, do not receive the task so the policy goes into effect. These
devices will eventually be turned on and connect. Shortly after they do, they run PolicySync.exe
and find they missed a scheduled task, and run it then.
With this method all devices eventually get the software package in the scheduled task, without
administrative baby-sitting. This method is the recommended best-practice.
 Policy: The Core Server sets the scheduled task as available for download. When a managed
device runs PolicySync.exe it finds that a scheduled task has software for it to download and
install. The device then performs that task.
 Push: The scheduled task notifies the targeted devices that a scheduled task has software for
them to download. They will download and install the software as set in the task.

 Ignore subsequent requests on successfully targeted clients: Select the checkbox to have
devices which are successful ignore policy requests for this task.
o Action type: Provides one of three portal options, plus an option of whether to allow users to run the
installation task as desired, at any time they so choose (if the option is displayed in the portal).
 Run automatically (do not display in portal): The software distribution package will install
without ever appearing in the portal.
 Recommended (display in portal): The software distribution package will appear in the portal,
will be selected, and will run when the user clicks [Launch].
 Optional (display in portal): The software distribution package will appear in the portal, will NOT
be selected, and will run when the user selects the package and clicks [Launch].
 Allow users to run as desired (keep in portal after selected): Will keep the item available in the
portal even after it has been installed.
o Frequency: Gives the option to run the task once, hourly, daily, weekly, or monthly.
 Additional Push options
o Accelerated push: With this enabled the Core Server communicates with targeted devices spawning
as many threads as needed to communicate with each device in the task, telling all devices to
download and install now. The discovery and communication process uses multiple processor cores
and threads. By default, accelerated push processes up to 64 targets concurrently, per thread.
o Use DNS resolution for discovery: This option tells the scheduler service to discover using DNS
rather than identification attributes which are in the Management Suite database.
o Wait for each machine to finish processing the task: This option is a deliberate slowing of
scheduled tasks. This sets the Core Server to discover devices, but to only schedule one device at a
time to perform the task. It will not tell the next device to run the scheduled task until the previous
targeted device completes the task.
o Wake up devices (not applicable to unmanaged devices): This option has the magic wake-on-LAN
packet sent as a part of the scheduled task.
o Accelerated wakeup (targets will not be shutdown): This option has the magic wake-on-LAN
packet sent as a part of the scheduled task, but no resume packet to have the device assume its state
prior to receiving the packet.
 Download options
o Run from source (execute on share): This option is equivalent to mapping a drive and executing.
This is the smallest bottleneck, slowest option, and is generally only used it a package requires
execution from the source.
o Download and execute: This option has the managed device download the software package to its
sdmcache directory, and then install from there.
o Pre-cache (download for a future task or portal-initiated action): This option has the managed
device download the software package to its sdmcache directory. It will not install until the user
initiates through the portal, or until another scheduled task using a different download option executes.
 Portal settings: Provides access to three portal options, plus an option of whether to allow users to run the
installation task as desired, at any time they so choose (if the option is displayed in the portal).

o Run automatically (do not display in portal): The software distribution package will install without
ever appearing in the portal.
o Recommended (display in portal): The software distribution package will appear in the portal, will be
selected, and will run when the user clicks [Launch].
o Optional (display in portal): The software distribution package will appear in the portal, will NOT be
selected, and will run when the user selects the package and clicks [Launch].
o Allow users to run as desired (keep in portal after selected): Will keep the item available in the
portal even after it has been installed. (This can only be selected if Recommended or Optional is
selected.)
 Agent settings: Provides ability to set the task to use a specific Agent Setting for both Distribution and patch
and Reboot settings for the task. You can Keep agent’s current settings, choose an agent setting from a
dropdown list, edit and select an agent setting, or use configure to create a new agent setting and select that
setting.

 Custom message: Allows creating a custom message to send out as a part of this scheduled task. If you
use this option, it will override custom messages designated in Agent settings.

 Schedule task: Grants access to the following options:
o Start time: Options to Leave unscheduled (do not reschedule task), Start now, and Start later. If there
are no items targeted, an indicator will tell you that.
o Target time zone aware: A checkbox to select whether to have the scheduled task send out
according to time zones, for a methodical rollout (as opposed to using the Core Server’s time zone
only).
o Repeat every: Allows retrying the task every hour, day, week, or month.
o Schedule these devices: Allow you to select:
 Devices that did not succeed: Select this to run the task for all devices that are in active,
pending, and failed states.
 Waiting or currently working: Select this to run the task for all devices that are in active and
pending states.
 All: Select this to run the task for all devices that are in active, pending, successful, and failed
states.
 Devices that did not try to run the task: This is the default setting, and should usually be used
the first time the task runs. Select this to run the task for all devices that are in a pending state.
 Legacy (pre-9.60) settings: These settings are for Mac, Linux, Unix, and pre- Management Suite 9.60
Windows managed devices.
o Delivery types: Select from the options: policy-supported push, policy, push, or multicast (cache
only).
o Delivery method: Select from one of the configurations of the corresponding delivery type.
Default Scheduled Task Settings

The Default Scheduled Task Settings makes it possible to create and assign a default scheduled task

setting. The enhancement was added primarily for the Rollout project tool which can be used for software
distribution, as well as for patch management. When a rollout project is used to distribute software, the default
task setting will be used.
To steps to create a default scheduled task setting are:

1. In the Management Suite Console, open the Scheduled tasks tool by clicking Tools or Toolbox >
Distribution > Scheduled tasks. (The Scheduled tasks tool opens in the bottom window of the Console.)
2. On the Scheduled tasks toolbar click the Configure settings icon, and click to select Default scheduled
task settings. (The Default scheduled task settings window appears.)
3. Configure the desired settings and click the [Save] button. (The Default scheduled task settings window
closes.)
Default scheduled task setting options

There are two pages of settings available in the default scheduled task setting options. They include:
 Push options: The push options page configures three settings:
o Accelerated push: Sets the number of computers per task to process simultaneously. The maximum
setting is 1000. The default setting is 64.
o General push Maximum task run time: This setting applies to both the push and the push portion of
policy-supported push tasks. The maximum task run time can be set as low as 15 minutes and as high
as 240 minutes. (Items not sent the command within the maximum task run time will be set to policy if
the option is set to policy-supported push, or to failed if the option is set to push.)
o Enable verbose policy task handler logging: Select this checkbox to enable verbose logging of the
policy task handler.
 APM maintenance: Sets the number of days to wait before cleaning up targets from the
LD_LDAP_TARGETS database table that are older than the selected number of days.

Software Distribution on the Managed Device
For Software Distribution to be carried on a managed device, the Management Suite Agent must be deployed.
The various configuration settings for Software Distribution in Agent Configuration settings are as follows:
Software Distribution Client

The first setting for Software Distribution in the Agent Configuration is the Software distribution checkbox in
the Start window. It is enabled and cannot be disabled. It will be a part of every agent deployment.

The second setting for Software Distribution in Agent Configuration is to select the desired agent setting for
Distribution and Patch. Here you can configure, edit, and select the agent setting for Distribution and Patch.
(For more information regarding the Distribution and Patch setting, please see the Agent Settings section.)
The third setting for Software Distribution in Agent Configuration is to select the agent setting for Portal
manager. Here you can configure, edit, and select the agent setting for Portal manager. Portal manager
becomes of use to the end user for software packages scheduled as Recommended (display in portal), or
Optional (display in portal).
 Portal Manager Settings: Here you select the portal manager setting you want to be installed on the

managed device. The edit and configure buttons open the Agent Setting tool where you can Create, Edit,
or Configure a Portal Manager Setting.
 Shortcut configuration: Allows you to select whether to add Portal Manager to the client’s:
o LANDESK Program Group
o Windows Desktop
o Windows Start menu
 Run Portal Manager when the user logs on: Allows you to select whether to run Portal Manager when
the user logs on.
Portal Manager Settings

Portal manager settings include three pages of configurable settings including: General, Applications, and
Branding.
 General: The options available in the General tab, or page, are:

o Name: This is where you name the portal manager setting.
o Allow resize: Selects whether the end-user can resize the portal window on the managed device.
o Allow close: Selects whether the end-user can close the portal window on the managed device.
o Launch maximized: Selects whether the portal window will be maximized on the managed device
when it is open.
o Set as default: Selects whether the portal manager setting will be the default when new Agent
Configurations are built.
o Default display options: Include the following options:
 View: Where the selected view can be set to List, Small icons, or Large icons.
 Available types: To select whether to allow the end user to select the option to display Apps,
Docs, and/or Links.
 Applications: Lets you select which applications will be available in the portal manager, and the order in
which they will appear. Choices include LaunchPad, and Task History.

 Branding: Allows setting how the portal looks on the managed device.
o Application title: Allows you to set the title in the portal.

o Choose title color: Allows you to select to color of the title line.
o Branding images: Allow you to set the Taskbar icon, the Corporate logo, and the Background image.
o Preview branding: Let’s you view the changes you have made.
 LANDESK Workspaces: Allows you to select whether to add LANDESK WORSPACES to the client’s
LANDESK Program Group.
Portal on the Managed Device

To use the portal on the managed device, it will require .NET4 to be installed. The Agent Configuration install
can include installing .NET4 if it is not already installed and the managed device.
The LANDESK portal manager has options to view the Launchpad and Task History.

Launchpad
The Launchpad is a tool that provides centralized application control for distribution packages, executables,
and URL links. With this tool, the administrator can easily control the presentation, installation, and run options
for end-user applications. The Launchpad tool offers end-users a single point to locate applications or short
cuts.
When using the Launchpad to link distribution packages, Just In Time (JIT) technology can be used. JIT
means the software application will not be installed, and consequently will not cost a license, UNTIL the end-
user clicks the icon the first time. The first icon launch will initiate installation of the software application and
then run it. Subsequent launches then launch the installed software application.
The Launchpad gives end-user the ability to filter what items they see. For items to appear, they must be
 scheduled to the end-user OR
 scheduled to the device used by the end-user
Since either the device or the logged in user are under consideration the LANDESK portal manager shows the
logged in user in the upper-right corner.
The delivery method employed by the Launchpad is a Launchpad Policy Delivery which is a Policy. It
appears in the Public delivery methods when the first Launchpad link is scheduled.
Launchpad Toolbar
 Launch: When the end-user selects an item on the Launchpad, the [Launch] button becomes active, and
if clicked, will run the selected item.
 Refresh: Initiates PolicySync.exe to check for updates.

 Status: Shows the status of a task.
 View: allows you to select the icon view or list view.
Task History
Task history lists the software tasks that have run on the managed device. It includes a search tool.
Launchpad Architecture
The Launchpad has files that run from the Core Server as well as files required on the managed device.
Core Server Files include:

 Launchpad.link.winui.dll: Contains the additions to the management console for the Launchpad interface
 Launchpad.link.data.dll: Contains data access functionality for Launchpad
 Launchpad.link.business.dll: Contains business login functionality for Launchpad
Managed Device Files include:

 LaunchpadAdminSettings.xml: Contains the user settings from the agent configuration which sets the
functionality available on the managed device pertaining to the Launchpad.
 Policy.client.Launchpad.exe: This is the Launchpad executable for the managed device.
 Shortcut.runner.exe: Executes software distribution links; allows the same link to execute the installation
as well as the actual application.
 Shortcut.runner.cgi.exe: This application is called by shortcut.runner.exe to provide rights for local
database access on the managed device.

 Shortcut.runner.cgi.sig: This is the signature file for shortcut.runner.cgi.exe.
 Shortcut.runner.cgilib.dll: This file contains business logic functionality for the shortcut runner
 Shortcut.runner.vroot: This xml file contains configuration information for the shortcut runner cgi.
 CreateFolderRoo.dll: Contains remote operation objects related to the creation of folders.
 LaunchpadRoo.dll: Contains remote operation objects related to Software Distribution and URL
Launchpad links.
 Policy.client.Launchpad.txt: Contains information regarding the launch and execution of Launchpad.
Reporting in Software Distribution

There are some very helpful standard reports offered concerning Software Distribution.
In the benefit analysis section of standard reports is the Software distribution benefit report. It can
generate reports by device or all distribution packages sent between dates configured by the person running
the report.
In the distribution status section of standard reports there are three (5) reports including: Delegated tasks,
Software distribution delivery status by device, Software distribution delivery status by device (multicast
enable), Software distribution delivery status by task, and Software distribution delivery status by task
(multicast enable). Each of these reports include options to select by Delivery Type, Location (LDAP), and
Device.
In the Dashboard editor tool, there are 16 charts available, in the Software Distribution section, to be added to
dashboards. These charts can assist in “at-a-glance” reporting.
Rollout Projects in Software Distribution

Rollout Projects is a tool which can automate Software Distribution as well as Patch Management. Rollout
projects are actionable objects, and as such can be:
 Owned by Users or Teams
 Grouped hierarchically in the Rollout projects tool
 Exported and synchronized to other Core Servers
Software Distribution Use Case

The use case for using rollout projects for software distribution, is to deploy software in a rollout manner (such
as from subnet-to-subnet, building-to-building, or site-to-site) until the software is completely deployed
throughout the enterprise in a step-by-step, methodical, manner.
While this can be helpful (especially in very large and diverse enterprises) some businesses do not find such a
use-case necessary. They can deploy software first on a small scale, testing and assuring the software being
distributed does not break something else. Then when they are ready to pull the trigger, and deploy the
software enterprise-wide, they use the self-elected multicast method of deployment, as it completely assures a
bare-minimum impact to both local and wide-area network traffic.
Example software package rollout project
To perform a staged rollout for new software, you can set up a rollout project to deliver the software to a small
group first, and then after it has been installed on 80% or more of those devices, wait for a week to make sure
things are working as designed. If the software fails to install on a significant percentage of devices within 2

weeks, set up the rollout project to send an email warning and don't push the software to a larger group.
However, if everything works as planned, push the software to a larger group.
This example has two steps:
 Step One
o Action: A scheduled task that distributes the software package to a small group.
o Exit criteria: An 80% success rate, meaning that the package cannot move to step two until the
success rate has been matched or exceeded.
o Email: You get an email if the package is still in Step One after 2 weeks.
 Step Two
o Action: A scheduled task that distributes the software package to a larger group.
Implementation
Configuring Rollout Projects includes creating steps to carry out the process. Rather than using if . . . then
logic, each step performs actions on all content in that step. Steps have three possible outcomes, including:
 Continue on to the next step
 Stop because the exit criteria have not been met
 Approval is required for content to continue to the next step
The Software Distribution Steps offer the following options:
Project Step Properties for a Software Distribution

Project Rollout
Steps contain Actions, Exit criteria, Email (which is optional), and Action history.
Actions
Schedule distribution task template: Set which delivery template to use to distribute the software packages
(such as Accelerated Push, Optional Policy, Policy Supported Push, Required Policy, etc.)
To add a template to be selected, open the scheduled tasks tool, right-click task template and click New. An
option will be presented to select software distribution template, or patch template.

Actions - Targets: Select devices, LDAP objects, queries, LDAP queries, device groups,
targeted scopes, and/or targeted time zones.
Exit criteria
Specifies the exit criteria that must be met before content in this step can advance to the next step of the
workflow (or exit the workflow). The exit criteria page offers the two following options:
 Keep content together: Select whether the keep all content together before advancing to the next step.
 Expected step duration (for charting purposes only): Designates the timeframe length the Gantt chart
will use when displaying the action history.
Exit criteria - Minimum duration

The minimum duration page offers the option to require a minimum duration after actions and lets you set the
minimum duration timeframe.
Exit criteria - Success rate

The success rate page offers the option to verify minimum package deployment success rate, and lets you
set what percentage of targets constitute a minimum success rate.
Exit criteria - Additional duration

The additional duration page offers the option to require an additional duration after success criteria is met,
and lets you specify the additional duration timeframe.
Exit criteria - Approval

The approval page offers the option to require approval before the content in the step can advance to the next
step of the project.
Exit criteria - Date time window

The date time window page offers the option to use a date time window to set when to exit a step. If the
success rate has not been met, this exits the step and triggers the duration has been exceeded email (if it is
configured).
Email
The Email section is dependent on the Email defaults settings of step duration exceeded, exit criteria met,
approval, and recipients all configured on the Rollout project properties page.
Email - Duration exceeded

The duration exceeded page lets you select whether to send email when duration is exceeded, and lets you
set to use project defaults (don’t send email), don’t send email, or send email.
Email – Exit criteria met

The Exit criteria met page lets you select whether to send email when exit criteria is met, and lets you set to
use project defaults (don’t send email), don’t send email, or send email.
Email – Approval
The Approval page lets you select whether to send email when approval is required, and lets you set to use
project defaults (don’t send email), don’t send email, or send email. It also allows you to only send on email
during a configurable timeframe to avoid an email blast.

Action history
An action history shows detail of successes, failures, and warnings. A Gantt chart of items in a project can be
accessed by double-clicking an item in a step of rollout projects.
There is a software distribution rollout project exercise.
Run the project processor on demand

For troubleshooting or testing a rollout project, you may want to run the processor immediately, process just
one project or one step, or apply an action to content more than once.
To run the project processor on demand
1. In Rollout projects tool, right-click a project or step and select Process now.
NOTE: If you try to process an item and the Process now option isn't available, make sure that the step and
the project are both set to Play and are not paused.
2. A prompt asks if you want to Re-apply actions even if they are already applied. When you re-apply
actions, the project processor runs just for that step and applies the actions to all content currently in the
step, even if they have already met the success criteria for the step. Whether or not you choose re-apply
actions, click OK to run the project processor.
The project processor runs for the selected step or project.
 If actions are re-applied, the Applied actions timestamp is changed, the minimum duration and post
duration timers are reset, and if there are scheduled tasks in the project or step, they are created again.
 If actions are not re-applied, content is evaluated to see if exit criteria have been met or if emails need to
be sent. Only content that is new to a step has actions applied.
Note
Emails associated with a project step are not considered an action and may be sent regardless
of whether or not actions are re-applied.
Pause and play a project, step, or content

Rollout projects, steps, and content in a project all have a state assigned: either play or pause. The state
affects whether or not it is processed when the project processor runs. The icons in the Rollout projects tool
have a play or pause overlay to indicate the current state of the item.
To change the state of a project, step, or content, right-click it and select either Play or Pause.
Tip/Comment
You must pause a rollout project or step before you can edit it.
 When a project is paused: The project processor excludes the project. No actions for the project are
applied, no notifications are sent, and no content moves from step to step.

 When a step is paused: The project processor does not process the content in the step. Content can be
moved into the step (either manually or by advancing from the previous step) but actions are not applied.
Content in a paused step does not advance to the following step even if it meets all of the exit criteria. If the
step is paused after an action is applied, timers continue to run even while the step is paused. For content
that does not have actions applied, any minimum duration or other timers do not start until the actions are
applied.
 When content is paused: No actions are applied to the content, no notifications are sent regarding the
content, and the project processor does not move it from the step it is currently in. If an action has been
applied and a timer is associated with the current step, the timer continues to run.
Application Builder
Ivanti has partnered with Acresso to bring our customers AdminStudio Lite. AdminStudio™ is an MSI
packaging tool that Ivanti is providing at no additional cost.
Here is what is included:

 A limited version of the AdminStudio Repackager - captures system changes in a snapshot mode.
 A full version AdminStudio Tuner - creates transforms files.
 Deployment wizard - to simplify distribution to a network location
For more information about AdminStudio please see this press release from Acresso:
http://www.flexerasoftware.com/company/newscenter/pressreleases/press-releases_10117.htm
To Download AdminStudio LANDESK Limited Edition:

http://www.flexerasoftware.com/promolanding/9996.htm
For a feature matrix on AdminStudio LANDESK Limited Edition and AdminStudio Enterprise Edition go to:
For an Installation Guide for AdminStudio LANDESK Edition go to:

For a Quick Start Guide for Creating an MSI using AdminStudio LANDESK Edition go to:
Here are some helpful tips that will assist you in your packaging (mostly taken from the Dao of the Windows
Installer). The following would be the most relevant Best Practices to users of AdminStudio LANDESK edition:
 Do not repackage an MSI.

 Do not repackage Windows Updates (i.e., security fixes or IE updates).
 Use a Clean System for Repackaging.
 Repackage on a system that represents, as closely as possible, your target environment.
 When customizing Vendor MSI package, use Transforms rather than directly modifying the package
(where possible).
 For help for understanding file versioning rules go to:
 Enable Windows Installer logging. For help on how to do this go to:
http://support.microsoft.com/?kbid=223300
 Test thoroughly before deployment
 Use Virtual Environments for Testing and Support.

 Use AlwaysInstallElevated policy for properly elevate packages. For more information go to:
Troubleshooting Software Distribution

The following tips are offered concerning Software Distribution:
Error: Could not run at client.

Cause: This is usually a rights issue. This could be a Distribution Package set in Accounts to run using the
Current user’s account and the current user does not have rights to copy down or install the software
application. It can also mean the user does not have rights to the share where the source software packages
are stored.
Resolution: Check user rights on the local managed device. Check rights to the resource share. Modify rights
as needed.
Error: The system cannot find the file specified

Cause: This can be an access rights issue to the source file. It can also mean the Distribution Package
requires additional files, and they are not included in Additional files window of the package.
Resolution: Check the Additional files in the Distribution Package. Modify the package to include files as
needed. Check user access rights to the source. Modify rights as needed.
Error: The folder name is invalid

Cause: The Distribution Package copies down an executable and then does a RunAtExit command to execute
an exe file while passing it command line parameters.
Resolution: Place all command line parameters in the [EXE Parameter] field and then rebuild the package.
Error: Failed, Result 0:3010 when deploying a .MSI file, when the installation actually succeeded.
Cause: The return code 0:3010 is not understood by the delivery method.
Resolution: Assign a return code 3010 in the Assign Return Code section of the Delivery Method.
Error: Client has initiated asynchronous policy execution the task stays in an active state.
Cause: There are multiple possible points of failure.
Resolution: Troubleshoot as outlined in the steps of DOC-33467 available at:
Gathering Server Side and Client Side Log Files

For troubleshooting purposes gathering log files, either from the Core Server or the Managed Device,
facilitates finding what step is failing in the process. To download log files, from either the Core Server or the
Managed device, do the following:
1. In the Console, locate a managed device from which you want to locate and download the log files. (This
can be in either the Network View or in the Scheduled tasks tool.)
2. Right-click on the device, and click Diagnostics. (The Diagnostics – Client Name window appears.)
3. Click to select Logs on the toolbar.
4. Click to select either Client or Core, depending on which log file source you want.
5. Choose the specific log file you want. It will download the file and bring it up for you.

Check for Understanding concerning Software
Distribution
1. What is the default scheduled task setting, and what solution does it provide?
2. What are bundle packages and what solutions do they provide?
3. What actions can be inserted between packages installed in a bundle, and how is this helpful?
4. What types of devices can receive mobile distribution packages?
5. When a windows actions distribution package contains a custom action, what windows application carries
out the action configured?
6. What is the bulk package credentials update tool, what solution does it solve, and how do you use it?

Operating System Provisioning
Module Objectives
 Cite OS Provisioning use case scenarios

 List features offered in OS Provisioning
 List OS Provisioning in agent-based and PXE-based scenarios
 Describe how PXE Representatives work in Management Suite
 Describe OS Provisioning Architecture
 List the steps to utilize OS Provisioning
 Outline the rights governing use of OS Provisioning
 Describe OS Provisioning template sections and actions
 Describe use of conditional branching in an OS Provisioning template
 Describe use of machine mappings with OS Provisioning
 Describe how to add drivers to the WinPE image file
 Implement Product Mapping Customization
 Change the wallpaper in the WinPE image file
 Create Boot Media to invoke OS Provisioning
 Describe use of Hardware Independent Imaging with OS Provisioning
 Describe how self-organizing multicast works with OS Provisioning
 List identifiers and how they work with OS Provisioning
 Describe how to use variables in OS Provisioning
 Describe how to use Device Naming
 List OS Provisioning options and their uses
 Describe how to provision MAC Devices
 Troubleshoot OS Provisioning

Operating System Provisioning Use Cases
Your business just ordered 8 new file servers and 50 new workstation PCs. Business needs require that four of
the eight file servers have a corporate standard server operating system, current patches, and five specific
server applications. The other four file servers will have the corporate standard server operating system and
current patches, but different software applications. The 50 new workstation PCs are replacing existing PCs
that are old and in needing of being retired. The 50 PCs will be deployed with the corporate standard
workstation operating system, current patches, the current user’s profile, then software each user requires to
fulfill their role. The way to do this, using the least amount of precious administrative effort, is with Management
Suite Operating System Provisioning.
A company goal has been made to update the Operating System on each computer and desktop in the
enterprise from an older version of Windows to a newer version of Windows. It is important for all software a
user utilizes to be brought onto the updated system. (In some cases the software needs to be updated to a
new version.) Management Suite Operating System Provisioning makes this possible.
An employee calls the helpdesk reporting that there is a message on the computer screen saying there is a
hard drive failure. A technician goes to the desk with a new hard drive and installs it. Without Operating System
Provisioning it would take hours to get that computer up and running. With OS provisioning, the workstation
can be up and running in just minutes.
What is Operating System Provisioning

Operating System Provisioning (OS Provisioning) provides a modular approach to make actions predictable,
reliable, and logged. Inasmuch as it is all scripted, it is predictable. Steps will be run one after another bringing
predictability and reliability. All actions are kept in a log, and reported back to the core server, so any errors
can be tracked and resolved, and there is proof for what was done on each provisioned device.
An example of a completed, combined template can include:
 Capture the User Profile from the legacy device

 Deploy the standard corporate Operating System to the new PC
 Use Hardware Independent Imaging to deploy all necessary drivers for the new PC (including reboots)
 Patch the new PC to the current patch level (including reboots)
 Restore the User Profile captured previously
 Deploy the applications (or updated versions of them) needed on the new device.
OS Provisioning works equally well on managed devices and new, bare-metal devices. OS Provisioning can be
launched from a managed boot, PXE (Pre-eXecution Environment), and external media boot (CD, DVD, USB
drive).
Features offered in Operating System Provisioning

There are many features providing great advantages in OS Provisioning, including Hardware Independent
Imaging, use of Targeted Multicast™, multi-tool support, bare-metal provisioning and other benefits as well.
Feature Benefit
Support for many imaging tools. No need to rebuild pre-existing images.

Possibility of changing from an expensive
imaging tool to one that comes free with
MANAGEMENT SUITE.
UEFI and BIOS support.
Automatic sensing for both 32-bit and 64-
bit support.
Automated SYSPREP Management.
Automation of post-image configuration:
Automatically create a SID, name the
device, join the Domain, and set up all
SYSPREP.INF and UNATTEND.XML support. network and localized settings.
Ability to name the device manually at start.

Eliminate the need for boot disks.
Both “new machine” and “in-place” migration
capabilities.
Automated process for both use cases
making deployment to new devices (PXE-
based) or existing managed devices
(Agent-based) quick and simple.
Management Suite PXE Representatives. Scalable by creating subnet based PXE
Representatives via self-electing subnet
services.
Self-Organizing Multicast Image Deployment. Saves network bandwidth and speeds up

the deployment of an OS image, when
sending multiple images on the same
network (i.e. classroom deployment).
Hardware Independent Imaging. One image can be deployed to a variety of

hardware platforms and vendors. No need
to keep images for each type of hardware
supported.
Preferred Servers. Images can be downloaded from the

closest preferred server, limiting WAN
bandwidth used.
Macintosh™ Provisioning. Images can be captured and deployed to

Macintosh devices.
Support for many imaging tools

There are various tools used with imaging. The three that are built into OS Provisioning include:
 ImageX: Written by Microsoft.
 Ghost: Written by Symantec.
 ImageW: Written by Terabyte (and comes with Management Suite).
If you implement OS Provisioning using any of these three tools, you do not need to know the command lines.
When you build OS Provisioning scripts, the command lines correspondingly build to the selected imaging tool.
Other vendor tools are supported, but the administrator will have to build the script.

Sector vs File Based Imaging
Imaging tools have two different approaches, sector-based and file-based. Sector-based imaging means data
is copied from sector to sector. This means the destination disk must be as large as or larger than the source
disk. (Usually, this is not an issue, because disks have generally gotten larger through the years.) File-based
imaging copies file-by-file from the source to the destination. This means the file system on the source and
destination disks must match. (Usually, this is not an issue, most use NTFS due to the large disk size support
offered by NTFS.)
UEFI and BIOS support

OS Provisioning can capture and deploy images for Windows 8 devices. The Unified Extensible Framework
Interface (UEFI) which replaces BIOS in 64-bit operating systems is fully supported. If WinPE needs to be
loaded on a UEFI device, it will load boot_x64.wim. The only PXE boot requirement is it must use IPv4 to PXE
boot. Support for BIOS remains in place using 32-bit PXE booting.
WinPE
In order to capture an image, or deploy an image, the Operating System cannot be in use (similar to trying to
copy a file which is in use, or overwrite a file which is in use). To have a Windows based computer in an
alternate Operating System, OS Provisioning uses Microsoft’s WinPE 4.0 (the Windows 8 version). WinPE is
available for free from the Microsoft Windows Automated Installation Kit (WAIK) and coincidently; ImageX is
available from the same source. Because of OS Provisioning’s use of WinPE, the first time a Management
Suite Administrator opens the OS Provisioning tool, a Microsoft Software License Agreement for WAIK is
presented. This is for an agreement between the administrator’s company and Microsoft. (Only after
acceptance of the Microsoft agreement will OS Provisioning allow creation of scripts which implement using
WinPE.)
Sysprep
When deploying an image to a device, if the device were to receive the source’s name, and secure identifier
(SID), error would be introduced to the network. In essence the network would be dealing with multiple
machines (and a network does not deal well with multiple personality disorder very well). To keep this from
happening, Microsoft introduces Sysprep.exe. Sysprep allows removing the name, SID, and domain
information, making the machine blank, or generic. When a device has run Sysprep, on its next boot up it will
run Windows mini-setup which creates a SID, names the device, and joins it to a domain. Alternatively, if
preferred, a SYSPREP.INF can provide all such data, and more, automatically to the managed device. OS
Provisioning facilitates creating a SYSPREP.INF or UNATTEND.XML file and stores in:
Program Files\LANDesk\ManagementSuite\landesk\files directory.
For more information regarding Sysprep, see the article Sysprep Technical Reference at:
http://technet.microsoft.com/en-us/library/dd744263%28WS.10%29.aspx
Provisioning Tool and Toolbox Selection

Noticeably changed in Management Suite version 2016, Provisioning has its own place in the Tools menu
and Toolbox.

It is no longer combined with the Distribution tool.
Agent-Based and PXE-based OS Provisioning

OS Provisioning supports the following methods:
 Management Suite Agent-Based: This deployment method works on a device which boots into a Base
OS, and then loads the Agent. The Agent facilitates copying files that become a run-once master boot
record (MBR) to boot into WinPE.
 PXE Based: This deployment method allows imaging devices with blank hard drives or an unusable OS.
Lightweight .NET PXE proxy agents load the device into WinPE. PXE loads the OS (in this case WinPE)
through the network access of the device, which is read from the PXE Representative.
How PXE fits into the DHCP process

 Client PC broadcasts Discover Packet – Hey! May I have an IP Address Please!
 DHCP Server broadcasts Offer Packet – Here! You may use this address, if you like!
- PXE Representative intercepts packet, adds task with packet – Here! Take this job with that address!
 Client PC broadcasts Request Packet – Hey! I will use that address, OK?!
 DHCP Server broadcasts Acknowledgement Packet – It’s yours! DHCP, add this to your list!
PXE Representatives
In order to PXE boot, each subnet, on which PXE Booting needs to occur, must have a PXE Representative.
Self-electing subnet services facilitates electing a PXE Representative for each subnet. Individual service
settings can be placed on each subnet.
Changes in Version 2016.3 for PXE Representatives

Prior to version 2016.3 the Management Suite Administrator selected which devices would perform the role as
PXE Representatives. The administrator would schedule a Management Suite distribution package to deploy
LANDESK PXE Services to run on devices selected to perform the role.
In version 2016.3 Self-electing subnet services elects the device to fill the PXE Representative role for each
subnet with PXE Services enabled. This ensures that each enabled subnet has one, and only one, PXE
Representative. If the PXE Representative goes off line, or disconnects from the network for any reason,
another PXE Representative will automatically take its place within an hour, ensuring PXE Services remain
enabled for the subnet.

Previous PXE Representatives
If the PXE Representative was not deployed using Management Suite, PXE services should be removed from
that device prior to deploying the Management Suite agent to the device. (Failure to do so would mean multiple
PXE Representatives would exist on the same subnet, rendering varied results, depending on which PXE
Representative would be the first to respond.)
If the PXE Representative was deployed using a distribution package from a previous Management Suite
version, the installation of the updated agent will take care of the PXE services. The device will only become
the PXE Representative in the 2016.3 version if it is elected to perform the role.
PXE Service Self-Election Process

The PXE Service self-election process occurs on the subnets set with the PXE Service enabled. The election
(through the assignment of points) gives preference to servers over workstations, and workstations over
laptops. The elected device is thereafter granted more points to give it preference, so the PXE Service is
unlikely to change the role to another device unless the elected device goes offline or disconnects from the
network. Each hour (by default) the elected device sends an election packet stating its own point value, asking
if there is a device with a higher value. If there was a device with a higher value (unlikely) the PXE
Representative would stop its LANDESK PXE Services, and the device with the highest points would start its
services and assume the role for that subnet.
Designating the PXE Representative

Because the previous version required assignment and deployment of the PXE Representative, some have
voiced the desire to assign a certain device to be the PXE Representative. To do this, the Management Suite
Administrator can assign a higher score to a device. To do so, use the following registry value:
HKLM\SOFTWARE\Wow6432Node\landesk\managementsuite\CSEP
Create a DWORD key called PXE_SVC_SCORE and assign the decimal value of 35.
The assignment of 35 or higher is a number greater than other scores that would naturally occur in the election
process. With this assignment the device will be the PXE Representative if it is on and connected to the
network. If the ‘designated device’ goes off or disconnects from the network, self-electing subnet services will
assign another device to be the PXE Representative. When the device with the assigned higher score rejoins
the subnet, it will become the PXE Representative at the next election cycle.
PXE Service Settings

Access the PXE service settings in the Management Suite Console:
1. Open the Self-electing subnet services tool. (Click Tools > Configuration > Self-electing subnet services.)
2. Expand Self-electing subnet services.
3. Click to select PXE service. (The right window will show all subnets present in the Management Suite
database.)
4. In the right window, click to select a subnet.
a. Click to select either the Enable or Disable icon on the Self-electing subnet services toolbar (or right-
click the selected subnet and select Enable or Disable). This selects whether to have a PXE service
on the subnet.
b. Click to select the Service settings icon on the Self-electing subnet services toolbar (or right-click the
selected subnet and select Services settings). The following window appears:

The PXE Settings include:
 Polling frequency: Sets how often the elected PXE representative will check for updated settings and
imaging files. (The default is 15 minutes.) If you change a setting or update a .WIM file the change will not
take effect on a subnet until the next polling interval check.
 TFTP block size: The default is 16384 for ia32 and for x64. This greatly speeds the PXE boot transfer.
Smaller sizes may be required in certain environments, though a smaller setting slows down transfers
(often substantially). VMWare in particular requires a block size of 1456.
 Allowed and Denied: Allowed MAC addresses are the only devices on the subnet allowed to PXE boot.
Denied means all devices listed will NOT PXE boot, while all others will. Use either allowed or denied, but
not both.
 WIM downloader settings: Allows selecting how to allow WIM files to download. Options include:
o Attempt Peer: Selected is on, unselected is off.
o Attempt Preferred Server: Selected is on, unselected is off.

o Allow Source: Selected is on, unselected is off.
o Bandwidth used from the core or preferred server (WAN): Select 1 – 100 percent.
o Bandwidth used peer-to-peer (Local): Select 1 – 100 percent.
PXE Boot Options

PXE Boot Options are set by accessing the Operating system provisioning tool, selecting the Preboot icon from
the toolbar, and selecting PXE Boot Options.
 Timeout: Set the number of seconds the PXE boot will allow a user to press F8 to view the PXE options.
 Message: Set the message that will appear during the wait time of the PXE boot.
 Always PXE Boot UEFI Devices: Select whether to Always PXE boot UEFI devices.
 Allow anonymous login for public templates: Select whether to Allow anonymous login for public
templates and ability to designate the user to assign the created scheduled task.
Changing these options does NOT require redeploying PXE Representatives.
The device elected to be the PXE Representative uses two services to perform its role. The services are:
 LANDESK PXE Service: Startup Type set to Automatic
 LANDESK PXE MTFTP Service: Startup Type set to Manual (but spawned by the LANDESK PXE
Service).
Troubleshooting PXE Representatives

If a device is elected but the LANDESK PXE Services will not run, check the following:
1. Assure the device has an approved certificate. We can elect devices without the device’s certificate being
approved, but the services will be blocked from running. (Starting with Service Update 2 you will be able to
see a status indicating the elected device does not have an approved certificate.)
2. Assure the device does not have dual NICs (both Wifi and Ethernet). (Wifi does NOT mix well with PXE so
we avoid it.)
Logs
PXE Representative log files can be found in the C:\ProgramData\LANDesk\Log directory.

 Tmcsvc.log: Logs the activity of the LANDesk Targeted Multicast service.
o The LANDesk Targeted Multicast service on the client handles the PXE Service for ALL elections.
o When a device is elected for the first time the LANDesk Targeted Multicast service installs the
LANDesk(R) PXE Service and the LANDesk(R) PXE MTFTP Service.
o The LANDesk Targeted Multicast service is responsible for starting and stopping the services
whenever elections take place.
 SelfElectController.log: Logs self-electing subnet services activity by service.
 Pxesvc.log: Logs the following information:
o LANDesk PXE Service Installation and settings.
o Boot.wim and Mac NBI download information.
o Communication with the core.
 Pxemtftp.log: Logs file transfer of boot.wim and NBI files to clients.
Preferred Servers
The size of images ranges all the way from 6 GB up to 20 GB and more. OS Provisioning provides a central
resource for deploying images, but with slow WAN links crossing geographic regions, it is built to leverage local
copies of images stored on Preferred Servers.
Preferred Servers are shares where images are stored for delivery to managed devices from a local source. If
the deployment script is configured so, the Preferred Server is sought out, prior to going to the central source
(classical download) for obtaining the image.
Preferred Servers can receive updated images from multiple mediums, but Management Suite customers have
asked Ivanti to leverage the bandwidth throttling ability built into Management Suite to update the Preferred
Server. Ivanti has answered with Content Replication.
Content Replication schedules regular updates of:

 Patches to be deployed
 Operating System Images
all of which can be deployed, utilized, and leveraged, by Management Suite.
Content Replication
To use Content Replication MANAGEMENT SUITE implements the following three roles. Namely:
 Preferred servers (targets) – local shares in various geographies that offer to managed devices its
resources (Distribution Packages, Patches, OS Images)
 Sources – shares containing original resources (Distribution Packages, Patches, OS Images)
 Replicators – Windows Devices with the Management Suite Agent, including Software Distribution, which
downloads resources from sources to the local sdmcache directory, and then copies those resources to
targets.
(Note: Multiple Sources can serve as resource to one or multiple Replicators. Also, Replicators can deliver
resources to one or multiple targets. Both Sources and Replicators can be set as a one-to-one or a one-to-
many resource.)
The steps are as follows:
1. Configure a Source (UNC share or Web share) to be replicated to Preferred Server (targets).
2. Configure a Preferred Server (target) for each subnet where a local source is desired.

3. Configure a Replicator to copy/update information from source(s) to target(s). This schedules the
replication updates.
For the most complete information on Management Suite content replication, please the article, How to use
LANDESK Content Replication, at: http://community.ivanti.com/support/docs/DOC-20779. This page
explains the entire content replication process, as well as providing links to other documents such as:
 LANDESK Content Replication – Console Options and Tools
 LANDESK Content Replication – Preferred Server (Target) Configuration
 How to Configure a Preferred Package Server
 How to set up a HTTP share for a Preferred Package Share
 Using Preferred Server in Patch Manager
 LANDESK Content Replication – Replicator Configuration
 LANDESK Content Replication Process
 LANDESK Content Replication Scenarios
Mac Provisioning
Operating System Provision includes ability to provision Macintosh devices. (For more information please refer
to the Mac Provisioning section.)
Provisioning Agent-Based Architecture
At the center of the Provisioning process is the agent, ldProvision.exe. It is located in the ldlogon
/provisioning folder. The agent calls plugins to launch each needed action. The agent is placed on the device
through a scheduled task, a PXE server, or a physical boot medium (e.g., a USB drive, or .ISO file on a CD or

DVD). LdProvision is launched from the device, allowing it to run and continue through reboots. The steps
ldprovision.exe takes are as follows:
 The agent requests a template’s configuration settings from a web service on the Core Server
 The agent checks the preboot type tag to ensure it is running in the correct preboot environment
 The agent performs the actions in the order designated in the configuration template
 The agent reboots the device (if necessary)
 The agent injects a version of itself into the target OS so it can continue working when the base OS loads
after the reboot
 The agent sends feedback to the web service on the Core Server.
Provisioning Agent Plugins
The plug-in libraries called by ldProvision help accomplish the steps of the template. To perform each action of
the template, ldProvision strips the root element off the XML file. For each action, it launches the required plug-
in and sends it to the XML snippet for that action. The combination of ldProvision remaining resident while
making calls to plug-ins provides flexibility and efficiency needed to handle all operations of the template while
enabling ldProvision to span reboots.
The plug-in libraries are found on the Core Server in the Program Files
LANDesk\ManagementSuite\ldlogon\provisioning\windows directory.
Provisioning Bare-Metal Devices

Provisioning can be launched to bare-metal devices in a variety of ways. One way is to create an identifier (e.g.
MAC Address, Serial number, IPMI GUID or Intel vPro GUID) in the Network View > Configuration folder. By

doing this the item is placed into the database, where it can be targeted for deployment via a scheduled task.
This can be done long before the device has been received from the manufacturer.
The steps to create an identifier in the database for a single device are:
1. From the Network View on the Console, click to expand the Configuration group.
2. Right-click Bare Metal Server and click Add devices.(The Add a bare metal server window appears.)
3. Click an Identifier type from the drop-down menu, (choices include MAC address, Serial number, and
Intel vPro GUID, and click [Add]. (The Bare Metal Server window appears.)
4. Enter a name in the Name field. Select the Identifier type, enter the corresponding information in the
Identifier field, and click [Add].
5. Click [OK]. (The Bare Metal Server window closes.)
6. Click [OK]. (The Add a bare metal server window closes. The added item is listed in the Bare Metal
Server pane.
Once the bare metal server is in the database it can be targeted for a scheduled task. Connect the device to
the network and boot it from an ldProvision boot CD, or a USB drive, or PXE boot the device. (At this point the
ldProvision agent contacts the Core Server and runs the appropriate provisioning template.)
The steps to create an identifier in the database for multiple devices from a .CSV file are:
1. Create a bare metal device (server or other device) by adding a device in Network View >
Configuration > Bare Metal Server > Add devices.
(The Add a bare metal server window appears.)
2. Click [Browse] to the right of the Import File field, and browse to the .CSV file, or type the path and
filename of the .CSV file.
3. Click [OK].
Provisioning Workflow
There are two scenarios to start provisioning templates on devices.
 Virtual boot (Vboot): For devices that boot, load the OS, and load the Management Suite agent. The
agent receives the provisioning command and executes the defined actions.
 Preboot eXecution Environment (PXE boot): For ‘bare metal’ devices that do not boot from the hard
disk. The device boots using DHCP, receives the PXE boot task, which invokes the provisioning template.
Vboot Workflow
The Vboot workflow is as follows:
1. Core Server
a. The Core Server has an OS Provisioning template.
b. The template is scheduled to a device, and the task is started.
c. The Core Server sends a command (prod) to the device to be provisioned.
2. Managed Device
a. The managed device receives the prod from the Core Server.
b. The client launches LDProvision.exe which sends a GetTaskXML call, asking the core for an .XML file
which contains the provisioning instructions.
3. Core Server: The Core Server sends the requested XML file, containing the provisioning instructions for
the device.
4. Managed Device

a. LDProvision.exe launches all subtask files in order to execute each of the actions in the provisioning
.XML file. In the case of Vboot, it will download, from a Preferred Server, the files it will need to reboot
into WinPE. The Vboot files are put in a local location, and the device does a one-time Vboot into
WinPE from there.
b. SetActionStatus is sent from the device to the Core Server, informing the Core Server of results of
running provisioning actions, as well as final status (success or failure) for the entire provisioning .XML
file, as well as result codes for the entire process; from WinPE boot, through deploying the OS and
loading drivers, to rebooting into the new OS and installing patches and software packages.
c. Logs of the process are made and kept on the client device throughout the process.
PXE Workflow
The PXE workflow is as follows:
1. Managed Device
a. DHCP boots, and during the process boots into WinPE and receives the provisioning command.
Tip/Comment
The DHCP boot and loading of WinPE can be from a network boot (from a PXE
Representative) or from an .iso file (via CD/DVD or portable USB thumbdrive).
b. The device connects to the Core Server and the available provisioning templates are made available in
a list.
c. The person at the device selects the desired template. This causes the device to launch
LDProvision.exe which sends a GetTaskXML call, asking the core for an .XML file which contains the
provisioning instructions.
2. Core Server: The Core Server sends the requested XML file, containing the provisioning instructions for
the device.
3. Managed Device
a. LDProvision.exe launches all subtask files in order to execute each of the actions in the provisioning
.XML file. In the case of Vboot, it will download, from a Preferred Server, the files it will need to reboot
into WinPE. The Vboot files are put in a local location, and the device does a one-time Vboot into
WinPE from there.
b. SetActionStatus is sent from the device to the Core Server, informing the Core Server of results of
running provisioning actions, as well as final status (success or failure) for the entire provisioning .XML
file, as well as result codes for the entire process; from WinPE boot, through deploying the OS and
loading drivers, to rebooting into the new OS and installing patches and software packages.
c. Logs of the process are made and kept on the client device throughout the process.
Provisioning in Detail
To start provisioning a device using Pre-execution Environment (PXE), two queues are provided, namely PXE
Provisioning (Windows PE) and PXE Provisioning (Linux PE). These queues can be seen in the
Configuration section under Network View. Devices can enter the queues in two ways; a bare metal device
can be placed via drag and drop from Bare Metal Server to a queue, or a provisioning template can be
scheduled, and a device can be placed via drag and drop to the task in Scheduled tasks. If a device is
targeted, it shows up in the PXE Provisioning folder/queue once the scheduled provisioning task runs. A PXE
Representative on the network finds the device in the queue and directs the device to boot into the
appropriate PE environment.

When a device enters the PXE Provisioning folder the MAC address of the device is written to a file in two
places; First, to a file called <CoreServer>-pxeconfig.xml found in c:\Program Files\LANDesk\
ManagementSuite\Provisioning\TargetLists. Second, to a file called pxeconfig.xml in the c:\Program
Files\LANDesk\PXE\System on the PXE Representative. This entry of the MAC address of the PXE booting
device tells the PXE Representative that the device has the LDProvision agent and needs to communicate
with the Core Server.
When a device has been in the PXE Provisioning folder/queue it is removed whether the provisioning task
completed successfully or failed. To re-enter the PXE Provisioning folder the device would need to be targeted
by a provisioning task or manually placed in the folder.
When a device is booted either by PXE, a boot CD/DVD, or USB, the LDProvision agent contacts the Core
Server. If the device has been pre-targeted by a provisioning task, it attempts to run the task. If the device has
not been targeted, the LDProvision agent presents the user with the Provision boot menu containing any
public provisioning templates.
Windows 10 Boot.wim
Enhancements to the Boot.wim files (boot.wim and boot_x64.wim) used for PXE booting include:
 Windows 10: They are Windows 10 based (so they need Windows 10 based drivers)
 PowerShell: They include PowerShell so PowerShell commands can be passed to PXE booted devices
 .NET: They include .NET so the client graphical user interface can display .NET applications
Steps to Utilize Operating System Provisioning

OS Provisioning Templates are logical blocks of .XML code. Provisioning is a graphical tool which facilitates
creation of .XML code. These blocks or templates can be chained together to accomplish a number of tasks in
sequence. There are three steps to utilize a template.
Step 1 – Create a Template

To provision a device, a template must first be created. The template contains actions, can include other
templates, and shows history of devices that have run it. Templates are saved as .XML files in the database.
Templates can be imported from other sources and modified to work in your environment. When exported,
templates become XTP (XML Template Page) files.
Step 2 – Configure the Template

When the template has been created, it must be configured by adding actions to it. Template actions are
sorted into template sections, to group them in a logical order. Some actions are available in all sections, while
others are strategically available in one or limited sections. It is in this phase the actions are created, the
variables are configured, the templates are linked, the history can be kept, and the XML code itself can be
viewed, edited, and exported.
Step 3 – Invoke the OS Provisioning Template

OS Provisioning Templates can be started in the following ways:
 Scheduled Task: From the Operating system provisioning tool, right-click the template you want to
schedule, and click Schedule Template. Then add the desired device(s) to the task.
 PXE Boot: After the PXE Boot, the device connects to the Core Server where the OS Provisioning
templates are able to be selected. Different ways to PXE boot include:

o Network Boot: Receives WinPE instructions from the PXE Representative through the network
o CD/DVD Boot: Receives WinPE instructions from the CD or DVD drive
o USB Boot: Receives WinPE instructions from the USB drive
Scheduled Task
The scheduling step matches an OS Provisioning task with one or more devices. (The devices can be added
singly, by device group, by query, or by LDAP container or query.) When a provisioning task begins, the job is
associated with the device’s record in the database, so the history remains associated with the device.
The Scheduled tasks window displays the scheduled task status while the task is running and when
completed. The scheduler service has two ways of communicating with devices: Through the standard
management agent (must already be installed on devices) and through a domain-level system account. The
chosen account must have the login as a service privilege and the specified credentials in the Configure
Services utility. Tasks fall under the following folders:
 My tasks: Tasks that the user has scheduled. Only the originating user and administrative users can see
these tasks.
 Public task templates: Tasks marked as publically available by users with appropriate rights. Anyone who
edits or schedules a task from this group will become the owner of that task. The task remains in the Public
task templates group and will also be visible to the User tasks group for that user.
 All tasks: Shows tasks created by the user and tasks marked as public.
Use Case for Scheduling an OS Provisioning Template

When you schedule an OS Provisioning Template and start the scheduled task, a read-only copy of the
template is created. It will have the same name as the template from which it was copied, with the date and
time appended to the end of the name. When you refresh the Operating system provisioning tool, you will see
the new template. The Locked column will have a “Yes” showing the template is read-only.
The Use case for this scenario is the first template was to use to test. If that template completes all actions as
planned, schedule the read-only locked template to run those actions on any other devices. The locked, read-
only, template is proven. Scheduling templates which have a locked copy already (whether scheduling the
original or locked copy) will NOT create another locked template.
Operating System Provisioning Rights

In order to use the Provisioning tool, rights must be granted to the Console user from the Management Suite
Administrator.
 The View right grants the ability to see and launch the OS Provisioning tool.
 The Edit right grants the ability to create a template in the My templates section of Provisioning templates.
 The Deploy right grants the ability to schedule templates the user has been granted the rights to see.
o If the user is granted the View right, in addition to the deploy right, he or she can schedule Public
templates for deployment.
o If the user is granted the View and Edit rights, in addition to the deploy right, he or she can schedule
Public templates and My templates for deployment.

 The Edit public right grants the ability to create templates in the public folder as well as move templates
from other users’ my templates and place them in the public folder.
Creating Templates
To create an OS Provisioning Template, click the New Template icon on the Operating system provisioning
toolbar.
Options are presented for four Template types:

 Empty Template
 Capture Template
 Deploy Template
 Mac Deploy Template
Templates can be grouped under My templates, or Public.
Template Sections
OS Provisioning allows for building separate templates of scripted actions, testing and finalizing them, and
then linking these finalized templates with other finalized templates.
Templates are grouped in five sections. The sections serve to help contain actions to a logical order. The five
pre-defined sections are:
 System migration: This section contains all tasks to perform PRIOR to booting the device into WinPE.
Examples might include: capturing a profile, or loading a specific driver. The last command of this section
will likely be to reboot the device and load WinPE.
 Pre-OS installation: These next three sections contain commands which should be done while WinPE is
loaded. In this section you might partitioning a drive.
 OS installation: While still in a WinPE pre-installation environment, you might deploy a desired Operating
System.
 Post-OS installation: While in this section you might perform final commands while in WinPE, and then
reboot to the deployed Operating System.
 System configuration: This section contains all tasks to perform AFTER rebooting from WinPE into the
base Operating System, such as Installing software, patches, etc.

Provisioning Actions
The Action list page gives access to set Provisioning actions to perform on the target device.
Provisioning offers the following 37 actions, in the following areas:
Action System Pre-OS OS Post OS System

Migration Installation Installation Installation Configuration
Capture Image X
Capture Profile X
Change Agent X X
Settings
Compare X X X X X
Variable
Configure Agent X
Configure target X
OS
Control Service X
Copy file X X X X X
Create directory X X X X X
Customize
Mapped X X X X X
Software
Delete file X X X X X
Deploy image X
Deploy Profile X
Device Name X X X X X
Prompter
Distribute X
software
Download file X X X X X
Download from X X X X X
preferred server
Execute file X X X X X

Hardware- X X
independent
imaging
Inject script X X X X X
Install Mapped X
Software
Install Service X
Join Domain X
Launch X X X X X
Template
Map/Unmap X X X X X
drive
Map/Unmap X X X X X
drive to
preferred server
Partition X X X
Patch system X
Reboot X X X X X
/shutdown
Replace text X X X X X
Scripted install X
Uninstall X
Service
Unzip file X X X X X
Update Registry X
Wait X X X X X
Windows 10 X
Update
Windows X
Refresh
Capture Image (available only in the OS installation section)

Use this action to capture an image from a target device. The capture image action uses preferred servers to
authenticate to the shares. This is set in the Content Replication / Preferred Servers tool. The Core Server
has to be set as a Preferred Server. The User name and Password fields in the Core Server’s Preferred server
properties are used to access the shares. The options available for this action include:
 Select the image type: From the drop-down menu select a tool of choice. Choose from the following:
o LANDESK ImageW V2: Comes with MANAGEMENT SUITE, and does NOT require a path to the tool.
Images have a .TBI extension.
o Symantec: Ghost.exe which has to be copied to a share. This requires you to specify the mapped
drive path to the imaging tool including the image tool name. Images have a .GHO extension and
spanned files have a .GHS extension.
o ImageX: Is available when the Microsoft agreement is accepted, enabling OS Provisioning. This does
NOT require a path to the tool. Images have a .WIM extension.

o Other: Is for choosing a tool not previously mentioned. It will require you to specify the mapped drive
path to the imaging tool including the image tool name. It will also require you to input the Command-
line parameters.
 Specify the UNC path to the image file, including the name of the image file: This is to define the
share name location and the file name that the imaging tool will use when it captures the image. (This is
ONLY an option if Symantec or Other is selected as the image type. This is not needed for LANDESK
ImageW V2, or ImageX is selected as the image type.)
 Command-line parameters: Sets the commands the imaging tool will use.
 Validate: Populates the Command-line parameters if LANDESK ImageW V2, Symantec, or ImageX, is
selected as the imaging tool. If Other is the selected imaging tool this field has to be manually entered.
Capture Profile (available only in the system migration section)

Use this action to capture a profile on a target device. The capture profile action runs the user migration
assistant to capture one or more profiles. To use this action, you need to know two things: First, where the user
migration assistant command XML file is located, second, the share where profiles are to be stored.
The capture profile action uses preferred servers to authenticate to the shares. This is set in the Content
Replication / Preferred Servers tool. The Core Server has to be set as a Preferred Server. The User name
and Password fields in the Core Server’s Preferred server properties are used to access the shares.
When saving profiles, you can specify a full filename, or you can use unique identifiers to create the file name
to store the profile.
To use the user migration assistant, the standard Management Suite agent must be present and minimally
include the standard Management Suite agent (including the inventory scanner, local scheduler, and software
distribution agents. Profile migration uses the software distribution agent to distribute files).
 Select user migration command XML file in UNC or HTTP format: To enter the location of the XML file
(usually in the ldlogon\uma\commandxml folder) on the Core Server. The .XML file contains parameters

used by the user migration assistant used when capturing a profile. There is a [Browse] button to aid in
locating the file. There is an [Edit] button for creating or modifying the XML file.
 UNC path for saved profiles: To specify the UNC path to store the profile when it is captured. (There is a
[Browse] button for finding or testing the location.) Profiles are saved with a .SMA extension.
 Specify full filename instead of using variables: Select this checkbox if you want to disable the filename
unique identifiers options. Selecting this will require the filename to be specified in the UNC path for saved
profiles field.
 File name unique identifiers: Select any combination of the computer name, MAC address, and serial
number to create the filename of each profile.
Change Agent Settings (available in system migration, and system configuration

sections)
Use this action to change the agent settings. You can deploy an agent with settings of the inventory scan, the
patch scan, and other actions deferred until much later, so as to not interfere with other actions the template
may still need to run. Then, after all other actions have run, set the agent setting so inventory scan, the patch
scan and other actions occur as regularly as needed.

The change agent settings action presents the ability to set each and every agent setting (all 27) contained in
the product.
Compare Variable (available in all sections)

Use this action to control the flow of conditional branching. You can select a variable, and based on the return,
have the actions which follow based upon whether the return is true or false.
Selections for this action include:
 Variable: Select from listed public variables

 Boolean: Select from:

o = (equals)
o < (less than)
o > (greater than)
o Between
o Contains
 Value: Type the criterion to compare
 Real time lookup: Uses values from the current computer record table if applicable. For example: if an
inventory scan updates the computer record, using this option will get the latest data for that record.
Configure Agent (available only in the system configuration section)

Use this action to install the Management Suite Agent onto the target device. This action can be the first action
after a reboot following Operating System install actions. Configurations are added to the drop-down menu as
created in the Agent Configuration tool.
This action can only be completed as part of a template that includes either the Scripted install or Deploy
image actions, or if the device has already been configured with an agent. The options available for this action
include:
 Use self-contained client installation package: If selected, options are presented to type or browse to an
Agent Executable Path. Options are also presented as to whether to Attempt Peer, Attempt Preferred
Server, and Allow Source to copy and run the file.
 Configuration name: Select which Agent Configuration to deploy in the action.
 Reboot if required: Will set a reboot to occur after the agent is installed.
Access to the share where the agent files are stored is provided by preferred servers. This is set in the
Content Replication / Preferred Servers tool. The Core Server has to be set as a Preferred Server. The User
name and Password fields in the Core Server’s Preferred server properties are used to access the shares.
Configure Target OS (available only in the post-OS installation section)

Use this action to designate the target operating system. This is helpful after a reboot of the operating system.
If the provisioning task has deployed a new operating system, you can select the Insert unique ID checkbox,
and if the existing device ID is found in the Management Suite database, it will assign the unique ID the device
had previously.
Control Service (available only in the system configuration section)

Use this action to start, stop, or restart a Windows service on the target device. This is a function available to
target devices running a Windows operating system.
 Service name: The display name of the service to act upon.
 Service control action: The action to execute on the service. Options are Stop, Start, or Restart.
Copy File (available in all sections)

Use this action to copy a file to the device running the OS Provisioning Template. Both the source and
destination can be located on a share. You must include a Map drive action prior to the Copy file action. The

Copy file action can be recursive, meaning that all files/folders below the source path can be copied,
maintaining their original structure. Wildcard characters are also supported (i.e., *.exe or ld*.*). The options
available for this action include:
 Source path and file name allows placing the device/share path and file name location of the file to be
copied.
 Destination path and file name: allows placing the location to which the file(s) will be copied. The file
name must be included.
 Copy subdirectories: Select the checkbox to include subdirectories.
Create Directory (available in all sections)

Use this action to create a directory on the device running the OS Provisioning Template. The two available
options here are:
 Path of the directory: where you can type the path to the directory being created.
 Create parent directory if needed: Select the checkbox to create the parent directory.
Customize Mapped Software (available in all sections)

Use this action to allow the person invoking the template to select which mapped software packages will be
installed. The Customize Mapped Software action allows manually selecting which software will be installed.
(For items to appear in the list to be selected, the software must be found, assigned in Software License
Monitoring, a distribution package must be assigned, and the customizable option must be selected, all in the
Product to Package Mappings tool.)
The Timeout (seconds) field sets how long the window will be open for the person invoking the template to
select which mapped software packages will be installed. Set the Customize Mapped Software action early in
the template so the person invoking the template can choose which software will be installed and can then
move on to other tasks without waiting. The software will be installed in the order selected when the template
invokes the Install Mapped Software action (which should be after the Install of the Management Suite Agent).
The Customize Mapped Software action must be called before the Install Mapped Software action, or ALL
software that is found in inventory, and assigned a distribution package in the Product to Package mappings
tool will be installed.

Delete File (available in all sections)
Use this action delete files on the device running the OS Provisioning Template. The path can be located on a
share. You must include a Map drive action prior to the Delete file action. The Delete file can be recursive; all
files/folders below the source path can be deleted. Wildcard characters are also supported (i.e., *.exe or ld*.*).
The options available for this action include:
 Path and file name: where you can type the full path and file name of the file to be deleted.
 Delete subdirectories: Select the checkbox to delete all subfolders and files below the source.
Deploy Image (available only in the OS installation section)

Use this action to deploy an image to a device. The deploy image action uses preferred servers to authenticate
to the shares. This is set in the Content Replication / Preferred Servers tool. The Core Server has to be set
as a Preferred Server. The User name and Password fields in the core Server’s Preferred server properties are
used to access the shares. The options available for this action include:
 Select the image type: From the drop-down menu select a tool of choice. Choose from the following:
o LANDESK ImageW V2: Comes with MANAGEMENT SUITE, and does NOT require a path to the tool.
Images have a .TBI extension.
o Symantec: Ghost.exe which has to be copied to a share. This requires you to specify the mapped
drive path to the imaging tool including the image tool name. Images have a .GHO extension and
spanned files have a .GHS extension.
o ImageX: Is available when the Microsoft agreement is accepted, enabling OS Provisioning. This does
NOT require a path to the tool. Images have a .WIM extension.
o Other: Is for choosing a tool not previously mentioned. It will require you to specify the mapped drive
path to the imaging tool including the image tool name. It will also require you to input the Command-
line parameters.
 Specify the UNC path to the image file, including the name of the image file: This is to define the
share name location and the file name that the imaging tool will use to deploy the image.
 Use Multicast: Select this box to use Multicast to deploy the image. (The use case intended to use
multicast is when deploying the image to multiple devices at once, this saves bandwidth, and makes the
process faster as compared to deploying the image to the devices one-at-a -time.)
o Timeout (seconds): Sets the amount of time the Multicast Representative will wait before
broadcasting the image file to devices on that subnet which also are receiving the image.
o Cache DiskID: Sets the disk that Multicast Representative will use to store the image files which will
be broadcast to receiving devices.
For more information concerning Multicast, please see the Self-Organized Multicast section.
 Command-line parameters: Allows customization of the way the image is captured.
 Validate: Populates the Command-line parameters if LANDESK ImageW V2, Symantec, or ImageX is
selected as the imaging tool. If Other is the selected imaging tool, this field has to be manually entered.
Deploy Profile (available only in the system configuration section)

Use this action to deploy a previously saved profile to a target device, using User Migration Assistant (UMA).
To use this action, you need to know the UNC path where the profile is stored. The deploy profile action uses
preferred servers to authenticate to the profile share. This is set in the Content Replication / Preferred
Servers tool. The Core Server has to be set as a Preferred Server. The User name and Password fields in the
core Server’s Preferred server properties are used to access the share where the profile resides.

To use the user migration assistant, managed devices must have the standard Management Suite agent
including the inventory scanner, local scheduler, and software distribution agents. Profile migration uses the
software distribution agent to distribute files.
 UNC path where the profile was previously saved: The location of the profile (.SMA file) to restore. (A
[Browse] button facilitates browsing to locate the profile.)
 Specify full filename instead of using variables: Select this checkbox if you want to disable the filename
unique identifiers options. Selecting this will require the filename to be specified in the UNC path where the
profile was previously saved field.
 Use automatic naming: Select the checkbox to use automatic naming. Automatic naming can be used if
the captured profile used automatic naming to capture the device using the Computer name, MAC address,
or Serial number.
This option can use Machine mapping. If a machine is defined in machine mapping a profile captured from one
device can deploy to another device assigned in machine mapping. (For more information, see the Machine
Mapping section.)
Device Name Prompter (available in all sections)

Use this action to prompt for keyboard input to name the device running the OS Provisioning Template. This is
optional because without it, the name is assigned from the following two steps:
 Variable: Create an “ldHostname” variable to replace text in the unattend script.
 Unattend script: Places the “ldHostname” variable into the “ComputerName” field of the script.
These two steps assign the Hostname on the device is provisioned.
If instead, you want to allow someone to input the name, inject the Device Name Prompter action as the first
step in the Pre-OS installation section. This will allow the user to start the OS Provisioning template, get the
prompt right-away in the process, then leave to do something else. The name will be in memory, and will be
used rather than what is in the variable “ldHostname” inserted into the “ComputerName” of the unattend script.
 Timeout (seconds): This sets the amount of time to allow the user at the device to input a name for the
device. If the name and typed and the “Enter” key is pressed, the timeout continues without further waiting.
If the name is not input before the time elapses, the action defers to either:
o LDHostname Variable in the “ComputerName” field of the unattend script (or the name typed in the
Device Name Prompter action if it is used).
o Mapped HostName as set in the “Source” machine column in the Machine Mapping tool.
o Name Template set in Edit Naming Template, accessible from Device Naming, accessible from the
Tools icon in the Operating system provisioning toolbar. This allows a Template to be created and
used when naming devices. (See more in the Edit Naming Template section.)
Distribute Software (available only in the system configuration section)

Use this action to distribute software applications created in the Distribution Packages tool to the device being
provisioned. You must place the Map drive action prior to the Distribute software action in order to authenticate
to the share. Also, the agent configuration action must be placed prior to the Distribute software action.
 Available distribution packages: This option presents all created packages in a drop-down menu.
o Type filter: This presents options to choose from All packages or limit those presented by Package
Type.
o Search: This presents options to search for packages by name. You can search in My packages or
Public packages. It includes a [Next] button if you type a package name.

Download File (available in all sections)
Use this action to download specified files using anonymous user (anonymous HTTP login) onto the device
being provisioned. If the files to be downloaded to the target device are located on a share, you must place the
Map drive action prior to the Download file action in order to authenticate to the share. The download file action
also includes the ability to define proxy server settings in order to gain access to the download location.
The Download file tab offers the following options:

 Source path and file name: The share path and file name location of the file to be downloaded. This can
be an http:// based path, or if previously mapped, a mapped drive, not a UNC share.
 Destination path and file name: The location, including path and file name, where the file will be placed
on the target device.
The Proxy server settings tab offers the following options:

 Use proxy server: Select this checkbox if you must gain access to the download location via a proxy
server. If this is selected, the Address and Port fields must be filled in.
o Address: Identifies the IP address of your proxy server.
o Port: Identifies the port number of your proxy server.
 Requires login: Select this checkbox to specify the Username and Password needed to use the proxy
server.
o User name: Enter a valid username with authentication credentials to the proxy server.
o Use variable for the password: Select this box to use a variable for the password. This variable is set
in Template variables under Sensitive data type, or in Public variables.
o Password: Enter the user’s password.
o Confirm Password: Enter the user’s password again as confirmation.
Download from Preferred Server (available in all sections)

Use this action to download data from a preferred server to a target device. The download can be a single file,
or the contents of a folder (including subfolders) on the source server. To use this action you must have
configured at least one preferred server using the Content Replication tool. The choice of which preferred
server is used depends on the settings you made when you set up preferred servers.
 Source: Specifies the path to the file or folder you want to download. This path MUST exist on all shares
that are used for preferred server downloads.
 Download directory: Select this checkbox to download the entire folder specified in the Source field. If
NOT selected, only the file specified in the Source field will be downloaded.
 Destination: Specifies the path on the target device to where you want to copy the file or folder.
 Preferred download locations: The three checkboxes let you specify which download sources you want
to use. They are listed in the order of priority. If all three checkboxes are selected, a peer download is
attempted first, followed by a preferred server, and last a download from the source.
o Attempt Peer: Select this checkbox to first attempt a peer download. (Peers are managed devices
which hear the broadcast of the destination device.) This option is to attempt to reduce the traffic load
on preferred and then the source server, in that order.
o Attempt Preferred Server: Select this checkbox to download from a preferred server. If one is not
found, it will then attempt to download from the source. This option attempts to reduce traffic load on
the source server, and its router.
o Allow source: Select this checkbox to download from the file source. This choice is only used if the
Peer and Preferred Server do not have the file or folder (if selected). This is the last option, for
bandwidth consumption reasons.

 Bandwidth used from core or preferred server (WAN): Adjusts the priority of this specific task as
compared to other network traffic. The higher the percentage slider is set, the greater the amount of
bandwidth used by this task, over any other traffic. Since WAN connections are usually slower, it is
recommended that this slider be set to a lower percentage.
 Bandwidth used peer-to-peer (Local): Adjusts the priority of this specific task as compared to other
network traffic. The higher the percentage slider is set, the greater the amount of bandwidth being used by
this task over any other traffic. Since LAN connections are usually faster that WAN connections, it is
recommended that this slider be set to a higher percentage.
Execute File (available in all sections)

Use this action to execute file commands on a device being provisioned. Execute files, along with any
command-line parameters, or return codes, you specify. The action utilizes a working directory parameter,
specified when configuring the action. The options available for this action include:
 Target path and file name: The file, including path and file name, to execute.
 Command-line parameters: Enter any supported command-line parameters to customize the way the file
is executed. Use parameters that ensure an unattended install, or else the Provisioning process will pause
while waiting for user input.
 Working directory: The program will be executed with reference to this directory. Any supporting files of
the program should reside in this directory. Command-line parameters start from this reference point.
 Expected return value: The executable file may return any number of different values. The user can
dictate what value or values are acceptable to move on to the next task. Options include Any, =, <, >, and
Between.
 Environment variables:
o Name: The name of the environment variable to use. Use double percent signs to specify local
environment variable (for example %%windir%%\system32\calc.exe).
o Value: The value of the variable.
 Capture command output: Places into the history the output captured when the file execution was run.
(This is helpful for troubleshooting and as part of the history provides verification.)
 Insert: Opens the Environment variable dialog, where you can add the name and value.
 Modify: Modify the selected variable.
 Remove: Delete the selected variable.
Hardware-Independent Imaging (available in the post-OS installation section and

System configuration sections)
Use this action to access a repository of device drivers that can be injected into provisioning templates or
deployment scripts. The hardware-independent imaging (HII) action can only be applied to devices running a
Windows 2000 (or later) operating system. The action runs the HII imaging tool (hiiclient.exe) in the
provisioning process. A base image is installed on the device, and the HII tool then injects the drivers that are
specific to the device model.
This is only available in the Post-OS installation section for templates based on the Windows preboot
environment. After the OS is installed, but before the device reboots, the HII tool detects the device model and
retrieves the drivers for that model. The drivers are installed onto the device and their information is included in
the registry. After a reboot, when the OS starts, it configures the drivers.
 Using UNC to download driver files: Select this checkbox to specify that only UNC is used to access the
HII repository.

If you use this action, include a Reboot action after it, in the Post-OS installation section.
 Force unsigned drivers to install: Selecting this checkbox will allow unsigned drivers to be applied during
HII in WinPE. Using unsigned drivers is a security risk, but you can assume that risk and install by selecting
this option.
Inject Script (available in all sections)

Use this action inject a script into the target OS file system. You can inject a sysprep.inf file into the deploy
image action or a unattend.xml file into a scripted install action.
Injecting a script copies the file to the target device and replaces any variables within the file. This action is
useful when to want to replace variables in any text file, such as a Windows answer files (like sysprep.inf or
unattend.xml).
If the Inject script action is used, it can only be done after the Operating System install action and before the
first reboot that follows the Operating System install. The options available for this action include:
 Script name: Select the script to install. (A script can be created by clicking the Install scripts icon, on the
Operating system provisioning toolbar.)
 Target file name: The location of the script you want to inject.
Install Mapped Software (available only in the system configuration section)

Use this action to install software using the rapid software deployment feature as configured in the Product to
Package Mapping tool, which can be launched by clicking the Product to Package Mapping icon on the
Operating system provisioning toolbar.
In the Product to Package Mappings tool, you can assign SLM Products to Distribution Packages. This
assignment sets which software will be installed on the newly provisioned device. The ability to make these

assignments enables upgrading an older version of software to a newer version, as part of an OS Provisioning
task.
 SLM Products: Populates with all software applications in the Monitored section in the Software License
Monitoring tool.
 SWD Packages: Shows all Distribution packages that are created and available to be installed.
 Remove Assignment: Allows removing the assignment so the software will NOT be deployed as part of
the Install Mapped Software action.
 Critical: Selecting this checkmark is analogous to selecting the Stop processing the template if this
action fails checkbox for a template action. When selected, if the particular software fails to install, the
action fails and will NOT continue to install other software associated as a part of the Install Mapped
Software action. When unchecked, even if the particular software package fails to install, the task will
continue to install other SWD Packages assigned to SLM Products. (All software which is attempted to be
installed by the action is logged in the OS Provisioning Template History.)
 Customizable: Selecting this checkmark makes the SWD Package able to be selected in the Customize
Mapped Software action.
 Disable: Selecting this checkbox means that although a product may be assigned, it will NOT be installed
as a part of the Install Mapped Software action. The use case scenario for selecting this is for testing
purposes. While testing, do not install the software which has the Disable box selected, while you test other
software as a part of this action, then, after all testing is complete, you can deselect the Disable box, and
have the action install all assigned software.
This option can use Machine mapping. If a machine is defined in machine mapping, software that was installed
on one device, can be installed to another device assigned in machine mapping. (For more information, see
the Machine Mapping section.)
Install Service (available only in the system configuration section)

Use this action to install a Windows Service on the target device. This requires the target device to be running
a Windows OS.
 Display name: The name you want to display to represent the service.
 Service name: The name of the service.
 Service Description: A description of the service.
 Target path and file name: The location and file name of the service you want to install.
 Command-line parameters: Enter any command-line parameters that will customize the way the service
is installed.
 Service startup type: Specifies the startup setting. This can be Manual, Automatic, or Disabled.

 Interactive service: Select this checkbox to display on the desktop any user interface that can be used by
the logged-in user when the service is started. This includes any message boxes the service may invoke
during the installation process. If this checkbox is NOT selected, the template runs without user interaction,
assuming the default selections of service messages. If the service displays any message during startup, it
may cause the template to pause until the message dialog box is closed.
Join Domain (available only in the system configuration section)

Use this action to join a target device to a domain or workgroup.
 Select operation type: A drop-down menu with options to Join domain or Join workgroup.
o Join Workgroup: Offers the Workgroup name option to enter the name of the workgroup.
o Join Domain: Offers the following options:
 Name: Enter the name of the domain you want to join.
 OU: Enter the Organization Unit you want to join.
 Username: Type the username required to authenticate to the domain (domain\user or
user@domain).
 Use a variable for the password: Select this checkbox to use a variable for the password. This
can be set in Template variables or in Public variables. Please see Public Variables affecting the
functioning of the template section for more information.)
 Password: Enter the corresponding password to the Username field above.
 Confirm Password: Enter the corresponding password to the Username field above.
Launch Template (available in all sections)

Use this action to launch another template as the next action, by clicking Select New Template. This action
will start a new template targeting the machine matched in the Machine Mappings tool. If no device is
matched, the machine will target itself, allowing templates to be chained.
Tip/Comment
If you have a new device for a user, associate the old device with the new device
in the Machine Mapping tool. Then launch a template to deploy the new Operating
System, the Mapped Software, and patches. Then, using the Launch Template
action, launch another template to capture the profile. After that, use the Launch
Template action to deploy the captured profile onto the new device.
Map/Unmap Drive (available in all sections)

Use this action to map or unmap a drive. (Please note that some systems do not accept drive mappings before
H.) The options available for this action include:
 Map/Unmap a drive: Lets you select from a drop-down menu whether to map or unmap a drive.
o Map a Drive offers the following options:
 UNC Path: Enter the desired path to where you want to map. A [Browse] box is available for ease
of use.
 Drive Letter/Mount Point: Enter the drive letter you want to assign.
 Username: Enter the name of the user credential to access the UNC path.
 Use a variable for the password: Select this checkbox if you desire to use a variable. This
variable is set in the Template variables under Sensitive data type, or in Public variables.

 Password: Enter the corresponding password to the Username.
 Confirm Password: Enter the corresponding password to the Username as verification.
o Disconnect a drive offers the option for a Drive Letter/Mount Point to enter the drive letter of UNC
source to disconnect.
o Connect a resource offers the following options:
 UNC Path: Enter the desired path to where you want to map. A [Browse] box is available for ease
of use.
 Username: Enter the name of the user credential to access the UNC path.
 Use a variable for the password: Select this checkbox if you desire to use a variable. This
variable is set in the Template variables under Sensitive data type, or in Public variables.
 Password: Enter the corresponding password to the Username.
 Confirm Password: Enter the corresponding password to the Username as verification.
o Disconnect a resource offers the following option:
 Resource path to disconnect: Enter the desired path you want to disconnect: (Example:
\\Doe\share).
Map/Unmap Drive to Preferred Server (available in all sections)

Use this action to map (or unmap) a drive on the target device to a path on a preferred server (or the source
server). The drive mapping stays in effect until the drive is explicitly unmapped, so you should include an
Unmap action in a template after an action that downloads data from a preferred server. To use this action, you
must have configured at least one preferred server using the Content Replication tool. The choice of which
preferred server is used depends on the settings you made when you set up preferred servers.
 Drive Letter: Specifies the drive letter to map (or unmap) in order to point to share on a preferred server.
 Unmap Drive: Select this checkbox if the action is to unmap a drive. The action will unmap the drive
specified in the Drive Letter field. (If NOT selected, the drive will map, rather than unmap.)
 Path: Enter the path to the drive in UNC format (\\preferredserver\sharepath). This path must exist on the
source server and all shares that are used for preferred server downloads.
 Attempt Preferred Server: Select this radio button to first attempt to map the drive to the nearest preferred
server that contains the specified folder structure. If no preferred server is found with the same folder
structure, an attempt will then be made to map the drive to the path on the source server.
 Require Preferred Server: Select this radio button to map the drive to the nearest preferred server that
contain the specified folder structure. If no preferred server is found with the folder structure, the task fails
(rather than mapping to the source server).
 Don’t Allow Preferred Server: Select this radio button to map the drive to the path on the source server,
without mapping to a preferred server.
Partition (available in Pre-OS installation, OS installation, and post-OS

installation sections)
Use the action to create a partition, remove a partition, remove all partitions, format a partition, mount a
partition, unmount a partition, make a partition bootable, or expand a partion. NOTE: The Boot environment
and target OS must be set prior to executing this action. The options available for this action include:
 Create default partitions: Use this action to create a default partition for either UEFI or BIOS based
computers. This action creates standard partitions as recommended for Microsoft operating systems
(Windows 7 or newer). This prepares the disk for use with ImageX or other file based imaging tools. The
action will detect UEFI and BIOS based computers and configure the partitions. Sector based imaging
tools, such as ImageW do not need this action.

The action will permanently delete all information on the hard disk. It will create the OS partition as drive C:
and the Boot partition will be mounted as drive S:
o Disk: Type the disk ID (Windows: disk number) or (Linux: name of the disk).
 Create partition: Use this action to create a partition on the target device.
o Disk: Type the disk ID (Windows: disk number) or (Linux: name of the disk).
o GPT: Select this checkbox to designate a GUID Partition Table (GPT) drive. If unselected, it
designates the drive as a Master Boot Record (MBR) drive.
o Partition type: Select the partition type from the drop-down menu. Selections include: Primary,
Extended, and Logical.
o Size (MB): The size of partition to be created, in MB.
o Offset: A number (in 8-bit format) indicating how far into the disk you want to create the partition.
o Mount: Select this checkbox to mount a drive letter
 Drive Letter: Enter the letter to assign the mounted partition.
o Format: Select this checkbox to format the partition.
 File System: Select the file system format. Selections include: NTFS, FAT, and FAT32.
 Quick Format: Select this checkbox to perform a quick format. If unselected, a full format will be
performed.
o Make Bootable: Select this checkbox to make the partition bootable.
 Auto assign partitions: Assign standard drive letters to OS and Boot partitions. This action discovers the
OS partition and possible separate boot partition and automatically assigns them standard drive letters.
This action requires that the OS be installed first and any boot partitions already be created, or this task
cannot assign the partitions.
o For UEFI and BIOS computers with a Windows 7 and higher OS with a separate boot partition the OS
partition will mount as C: and the Boot partition will mount as S:
o For computers with a Windows XP and Windows 7 and higher OS without a separate boot partition the
OS/Boot partition will mount as C:
 Remove partition: Use this action to delete a partition on the specified disk.
o Remove from disk: Type the disk ID (Windows: disk number) or (Linux: name of the disk).
o Partition Id: Type the partition number to be removed.
 Remove all partitions: Use this action to delete all partitions on the disk.
o Remove from disk: Type the disk ID (Windows: disk number) or (Linux: name of the disk).
o Partition Id: Type the partition ID
 Format partition: Use this action to create a file system structure on a partition.
o Logical disk drive-letter (Windows only): Drive letter of the partition to be formatted.
o File system: (Windows: FAT, FAT32, or NTFS) (Linux: ext2, ext3, reiserfs, or linux-swap)
o Quick format: Select this checkbox to perform a quick format on the partition. If unselected, a full
format will be performed.
 Mount partition: Use this action to mount a partition of the target device.
o Disk (Windows only): Disk number to be mounted.
o Partition id (Windows only): Partition number to be mounted.
o Logical disk drive-letter to create (Windows only): Drive letter to assign to the partition to be
mounted.
 Unmount partition: Use this action to unmount a partition of the target device.
o Disk (for both Windows and Linux): Disk number to be unmounted.
o Partition id: (Windows: Partition number to be unmounted.) (Linux: device name of the partition to be
unmounted.)
o Logical disk drive letter to remove (Windows only): Drive letter of the partition to be unmounted.

 Make bootable: Use this option to make the partition bootable.
o Disk: Disk number to be made bootable. (Windows: disk number.) (Linux: Name of disk.)
o Partition id: Partition number to be made bootable.
o Bootable: Select the checkbox to make the partition bootable.
 Expand partition: Use this option to expand the last partition on the drive. Free space must be available.
o Disk: the disk number to be expanded. (Windows: disk number.) (Linux: Name of disk.)
o Partition id: (Windows: Partition number to be mounted.) (Linux: Device name of the partition.)
o Size: The new size of the partition in MB. If you leave this blank, the partition will be expanded to fill
the remainder of the disk.
Patch System (available in the system configuration section only)

Use this action to scan a device for vulnerabilities and remediate them. It is good to place this action deploying
the OS and installing the Management Suite agent on a device. The options available for this action include:
 Scan only: Scans the device for vulnerabilities and will report but not remediate.
 Scan and remediate vulnerability: Scans the device for a specific vulnerability, designated in the
Vulnerability ID field below. (It will remediate the vulnerability if the Scan and repair settings are configured
to autofix, and if the vulnerability is set to autofix.)
o Vulnerability ID: Enter the vulnerability ID to scan (and autofix). (If left empty this action will fail.)
 Scan and remediate group: Scans the device for a group of vulnerabilities. The Group ID field below
designates which group of vulnerabilities to scan (and remediate). (It will remediate the vulnerabilities in the
group if the Scan and repair settings are configured to autofix, and if the vulnerabilities are set to autofix.)
o Group ID: Enter the Group ID to scan (and autofix). To help select the group, a browse button is
located to the right of the Group ID field.
 Scan and repair settings: Sets the scan and repair setting configuration to be used during the scan. If
remediations take place, this assigns how rebooting will occur following the remediations.
The vulnerability definitions should be updated in download updates prior to executing this action. All patches
to be remediated must be downloaded for remediation to occur.
Reboot/Shutdown (available in all sections)

Use this action to reboot or shutdown the device being provisioned. A reboot must immediately follow the OS
install action. Upon reboot, the provisioning agent resumes the template to continue the tasks. Multiple reboots
are supported. The options available for this action include:
 Reboot: Shuts down and restarts the device.
 Shutdown: Shuts down the device at the end of the provisioning task and leaves it off. (This must be the
last provisioning action in the template, as the machine will power down. If provisioning actions were to be
placed after this command, they would not run.)
 Boot to Managed WinPE (Virtual Boot): Shuts down the device and restarts it loading WinPE. (This
action will copy the WinPE environment to the hard disk and set the boot record to run once to boot into
WinPE. A PXE server will not need to exist in the network to perform this action.)
 Confirmation message timeout (in seconds): Places a wait after the shut down and restart to pause
before continuing provisioning actions. (Recommended use: 2 – to start actions after a two second wait
after the reboot is done.)
Replace Text (available is all sections)

Use this action to replace text in an existing file on the device being provisioned. The options available for this
action include:
 Source path and filename: Type the path and filename of the file to have text replaced.

 Find what: Type the existing text that is to be replaced.
 Replace with: Type the text that is to take the place of the existing text.
o Replace first occurrence: Replaces the text the first time it is encountered.
o Replace all occurrences: Replaces the text each time it is encountered.
Scripted Install (available is the OS installation section only)

Use this action to initiate the scripted install of an Operating System on a target device through the use of
custom scripts. The options available include:
 UNC path to installation source (\\server\source\i386): This is the path where the executable file is
found within the installation source (Winnt32.exe).
 Domain and user name: The username credentials granting rights to the installation source.
 Use a variable for the password: Select this checkbox to use a variable for the password. This variable is
set in Template variables under Sensitive data type, or in Public variables.
 Password: Enter the password to the corresponding user which grants access rights to the installation
source.
 Confirm Password: Enter the password to the corresponding user which grants access rights to the
installation source again as confirmation.
 Additional parameters passed to setup: Parameters to the passed to the install file when it is executed.
For Winnt32.exe, the provisioning handler automatically fills in the unattend (/unattend) and the source (/s)
arguments. These are generated from the path that was given in the Winnt32 path, and from the script that
has been selected.
 Installation script: Allows selection via a drop-down menu of the unattend.xml file or sysprep.inf file (or
other file name) to be used when installing the OS.
 Force Reboot: Select this checkbox to force a restart after the scripted OS installation.
Uninstall Service (available in the system configuration section only)

Use this option to uninstall a service from a target device.
 Service name: The name of the service to be uninstalled.
Unzip File (available in all sections)

Use this action to unzip the contents of a package. The options available for this action include:
 Source path and file name: Type the path and file name of the package to be unzipped.
 Target path: Type the location where the package is to be unzipped. (If there is an existing directory/folder,
any duplicate filenames will be overwritten.)
 Create target directory if it doesn’t already exist: Select this checkbox to create the target directory if it
is not already created.
Update Registry (available in the system configuration section only)

Note: This action only shows in the System Configuration section IF the target OS is set to Windows.
Use this action to add or remove keys or values to the registry, or import a registry (.REG) file. (Remember that
editing the registry incorrectly may damage your system, potentially rendering it inoperable. Before making
changes to the registry, you should back up any valued data on the computer.) The options available for this
action include:
 Registry operation: Select from the drop-down menu any of the following actions:
o Create key: Creates a folder on the left side of the Registry Editor. It names the folder what is typed in
the Key field which follows.
 Key: Type the name of folder and path to be created in the registry.

o Delete key: Removes a folder on the left side of the Registry Editor. It deletes the folder typed in the
Key field which follows.
 Key: Type the name of the folder and path to be removed from the registry.
o Delete value: Removes the expected value of the key.
 Key: Type the registry key containing the value you want to delete.
 Value: Type the registry value you want to delete.
o Set value: Sets the value in the registry key you designate.
 Key: Type the registry key containing the value you want to set.
 Value: Type the registry value you want to set.
 Type: Select from the drop-down menu any of the following options: String value, DWord value,
Multi-string value, Binary value, or Expanded string value.
 Datum: Type what you want saved in the registry value.
o Import file: Use the [Browse] button to find the .REG file to import. The box above this field will
display the contents of the file.
Wait (available in all sections)

Use this action to add a pause in the template action. This is either for a specified time, or until a required file
has been created. The options available for this action include:
 Time: Select this option to place a pause (in seconds).
o Number of seconds to wait: Type the number of seconds you want to pause.
 File: Select this option to place a pause until the file in the specified path exists. This can be useful when
an action requires an application to install a file. When the file is created, the template continues to the next
action.
o Wait for file to exist: Enter the path and file name desired.
o Maximum number of seconds to wait: Waits for the specified time (in seconds). If the time passes
and the file never appears, the template continues to the next action.
Windows 10 Update (available in the system configuration section only)

Use this action to select the path and file name to the Windows 10 ISO file that will be used for the update.
Windows Refresh (available in the system migration section only)

Use this action to act upon a target device with a Windows 8 or 8.1 OS. These call the Windows actions for
Update and recovery. The options available include:
 Reset: To remove everything and reinstall Windows. If you want to recycle your PC or start over
completely, you can reset it to its factory settings. This will use the .wim file included in a default image
(without reformatting the drive).
o Fully clean the drive: Select this checkbox to format the drive prior to overwriting the drive with the
.wim file.
o Use default local WIM: Select this checkbox to use the .wim file included in the default OS.
o Failover to specified wim if no local WIM present: Allows using a .wim file (specified in the UNC
path including WIM filename to use field).
 UNC path including WIM filename to use: Type the UNC path and file name of the .wim file to
use. (The Use default local WIM checkbox must be UNCHECKED to use this option.)
 Refresh: To refresh the target PC without affecting the user profile items (My Documents, My Music, My
Pictures, etc.). This uses a .wim file to overwrite the drive without affecting the user profile items.
o Use default local WIM: Select this checkbox to use the .WIM file included in the default OS.

o Failover to specified wim if no local WIM present: Allows using a .wim file (specified in the UNC
path including WIM filename to use field).
 UNC path including WIM filename to use: Type the UNC path and file name of the .wim file to
use. (The Use default local WIM checkbox must be UNCHECKED to use this option.)
 Create and assign local WIM: To refresh the image with the .wim file included in the default OS.
 Assign specified image as local WIM: To refresh the image with the .wim file designated in the UNC path
including WIM filename to use field.
o UNC path including WIM filename to use: Type the path and file name of the .wim to use to refresh
the image.
Conditional (If . . . Else) Branching

The ability to use a condition in a provisioning template provides a new, powerful, dimension. You can build
logic into the provisioning template. You can have a set of actions run for an IF condition, and have a separate
set of actions run for an ELSE condition.
In the above example, the template is conditioned upon a variable set by the attribute
Computer.System.ChasisType = Laptop. If the statement is true, it will deploy the “Laptop Image”, while if not
true, it will deploy the “Desktop Image”. You can compare a variable to a value, based on inventory.
Conditional branching is only able to be used on one level. Branch nesting (a condition within a condition) is
not allowed.
Machine Mapping
This tool allows for mapping one device to another. This is used with three actions: Deploy Profile, Install
mapped software, and Launch template.
To launch the Machine Mappings tool, click Tools > Distribution > Machine Mapping.

o Days Valid: Sets the number of days the Machine Mapping will be assigned.
 The use case for this setting is to create a safety feature. If a machine mapping is used, the Last
Used field populates with the date and time the OS Provisioning Template uses the machine
mapping. With the field populated, the Days Valid field is put into effect. If an OS Provisioning task
tries to use the mapping beyond the setting in the Days Valid field, the mapping is ignored. You
likely do not want the mapping to be valid months from now when the task might run unexpectedly
on a device, overwriting its hard drive.
o Remove: Deletes the assignment of the Source and Destination devices.
o Reset Used: Removes the contents of the Last Used field.
o Refresh: Refreshes the Machine Mapping tool view. This will update the view to include showing
mappings that have been used by OS Provisioning Templates being run.
o Search: Allows searching for a device to place it in the Source and Destination columns.
o Source: The machine that is being replaced with another device. (This would be the old device.)
o Destination: The machine that is replacing another device. (This would be the new device.)
o Last Used: The date and time the Machine Mapping assignment was last used. (Populating this field
activates the Days Valid setting, so the machine mapping assignment will be ignored if the number of
days set in the Days Valid field have passed.)
Manage Drivers to the Windows PE Image

A PXE boot copies WinPE into memory via the network interface card (NIC). Therefore, with each new NIC
that is introduced into the enterprise, a new driver needs to be added to the Windows PE image offered by
each PXE Representative.
To manage drivers in the Windows PE Image user for network boot, download the Windows 8 driver (to match
the WinPE 4.0 version OS Provisioning uses) and add it to the Windows PE image.
To add the new driver to the WinPE image, click Manage Drivers in WinPE Image from the Preboot option in
the Operating system provisioning toolbar.
Management Suite helps facility an easy download of Dell drivers in the Download updates tool. In the tool, is
a checkbox to select Dell drivers for winpe. Selections can be made to download drivers for many Dell makes
and models of Latitude, Optiplex, Precision, and Tablet devices. Once downloaded, the drivers can be added
to the WinPE image.

To access the article, How to Add Drivers to WinPE for LANDESK OS Provisioning, please go to:
To access the article, About Windows PE Versions used in LANDESK Management Suite, please go to:

Branding
The provisioning banner can be changed, the background and foreground colors are selectable, and the title is
configurable. You can place your company name in the title, select your company logo in the banner, and
choose company colors as the background and foreground colors. Having your company logo and colors
reassures end-users against rouge software.
To access the Default Provisioning Branding open the Operating system provisioning tool, select Tools on the
toolbar, and select Branding.

The client view has also been enhanced to be more informative to the viewer as provisioning actions occur.
Product Mapping Customization

A previous version brought in the versatile and adaptive product to package mapping feature. This feature
allows monitored products (found in the inventory of the device) to be installed following the OS installation,
with the inclusion of the install mapped software action in the provisioning template. This placed all software
(which was on the old device or OS) onto the new device, or device with a new OS. However, this was not
customizable. What is new to this version is the ability to select software as customizable.

When software is marked as customizable in the product to package mappings tool, it can optionally be
selected to be installed when the customize mapped software action runs in a provisioning template. Once
software is selected, it will be installed when the install mapped software action runs in a provisioning
template.
Place the customize mapped software action early in the provisioning process, before booting into WinPE.
When the customize mapped software action runs, someone can select which of the mapped software
packages will be installed by the install mapped software action, which is typically placed as a final step in the
provisioning template.
Changing Wallpaper in WinPE

An organization can change the wallpaper that appears during the WinPE boot (e.g. to include the company
logo). To do this make a .JPG file (1024 x 768 recommended) and add it to the WinPE image by clicking the
Preboot icon on the Operating system provisioning toolbar and clicking Change WinPE Wallpaper.
Options are presented to browse to and use the desired .JPG file, as well as 32-bit and 64-bit options.
Create Provisioning Boot Media

If you want to provision devices which are not connected to a network that can see the Core Server, or that
have slow WAN links and no Preferred Server locally, you can create a disconnected template on a USB
thumb drive. When you do this, OS Provisioning deletes all data on the USB thumb drive, makes the drive
bootable, and copies the necessary files to the drive, such as WinPE, drivers, the OS image you want to
deploy, and so forth.
To create the provisioning boot media:

Click Create Provisioning Boot Media from the Preboot icon in the Operating system provisioning tool to
create a bootable .ISO file on a CD, DVD, or USB flash drive.
 Core Server: Provides the source WinPE.iso file for use during the boot from the CD, DVD, or USB drive.
 Bootable ISO: Select this option to create the WinPE.iso file to the location specified in the Destination
Path field.
o Destination Path: Type the path and filename to create the WinPE.iso file for the Boot process.
 Bootable USB Drive: If a USB Drive is mounted, this option becomes available. Select the desired USB
Drive location from the dropdown.
NOTE: The use case for a Bootable USB thumb drive, is to use OS Provisioning Template on devices which
are not connected to a network that can see the Core Server, or that have slow WAN links and no local
Preferred Server.
If you create boot media on a USB thumb drive, all data will first be deleted from the drive, and the drive is
made bootable. The necessary files, such as WinPE, drivers, and the OS image you want to deploy, are then
copied onto the drive. You can copy the OS Provsioning Template onto the drive using the Create
disconnected template option. (To see more about refer to the Create disconnected template options
section.)
Hardware Independent Imaging

Hardware Independent Imaging (HII) allows you to deploy a single image to a variety of hardware platforms,
whether they are laptops, desktops, servers, etc., regardless of vendor. This eliminates the need to have an
image for each make and model computer, and each operating system supported in an enterprise. One
Management Suite customer, upon implementing HII, went from having over sixty (60) images, down to having
just three (3).
The key to effectively using HII is to have a repository of drivers for each piece of hardware supported, and
each operating system supported. OS Provisioning provides an easy way to add drivers to the library, and
uses a database (drivers.db3) to match drivers with the corresponding hardware and OS.

The single-most common error in OS imaging is correctly matching the correct driver to its accompanying
hardware. For instance, it is NOT uncommon for trackpad drivers to incorrectly match to mouse drivers, nor is
it uncommon for network interface card drivers to erroneously mismatch. To address these mismatch issues,
Management Suite has the HII Driver Management tool.
The HII Driver Management tool has auto assignment functions. With Auto Detection you can see device-by-
device, and driver-by-driver, what is detected. You can elect to keep and use what was detected, or you can
remove what was detected and assign another driver. This method and view of drivers and assignments grants
insight to see in an overall way, and in a granular way, drivers installed after OS deployment.
You can either disable drivers which are incorrectly chosen and installed (hoping that AutoDetect will assign
the correct driver with its next selection) OR you can bypass AutoDetect and assign drivers to a make, model,
OS, and architecture. The tool includes an Auto Detection feature. When you get a new make and model
computer, install the Management Suite agent. Then, HandwareInfoUtility.exe runs 15 minutes after the agent
is installed, plus a randomized time, and reports up the new computer’s installed devices and their associated
drivers. At this point, they could be assigned taking away the risks associated with AutoDetect.
How Hardware Independent Imaging Works

An overview of how the HII process flows is as follows:
1. The OS Provisioning Template sends an action to boot the device into WinPE. In the WinPE environment,
the HII tool will select the appropriate HAL.dll file and load it.
2. The OS is deployed to the device, but before it boots into the target OS, the HII imaging script determines
which drivers the device needs, and copies the driver files to the device’s hard disk.

3. The drivers are added to the device’s registry so that when the OS boots, the Windows setup detects the
new drivers, installs them, and configures the device with drivers.
4. Windows then restarts with the drivers running and the Management Suite Agent is installed.
Steps to Implement Hardware Independent Imaging

1. Download the Drivers that will be need by the devices.
2. Set up the Core Server as a Preferred Server.
3. Add the Drivers to the HII Drivers Repository.
Download the Drivers

To add to the repository, download drivers from the manufacturer’s websites. Some drivers are packaged into
grouped executable files, and will need to be expanded out. Download the drivers for each OS that runs on the
hardware platform, and group them by OS. The format for the grouping might best be:
 Vendor – Hardware Manufacturer Name.
 Hardware Model – Make and Model of Computer
 Operating System – Windows 8, Windows 7, Windows XP, etc.
 Driver Type – i.e. Hard Disk, Network Card, Bus, Video, Sound, Keyboard, Mouse, etc.
(For example, if I have a group of HP Pavilion HPE h8-1300z Desktop devices, and I run Windows 8 on them, I
should download ALL Windows 8 drivers for those desktops, expand the drivers, and put them in a Windows8
directory named for the hardware. Later, I may run Windows 8.1 on them, and when that occurs, download and
expand all drivers for Windows 8.1 for that hardware, and put them in a Windows 8.1 directory named for the
hardware. I also have groups of Lenovo ThinkPad W500 laptops. I run Windows 8 and Windows 8.1 on those
laptops. I should download 8 drivers, and Windows 8.1 drivers, for the W500s, and them in directories named
for the OS under a directory named for the hardware. Once the libraries are collected, copy them to the Core
Server’s,
Program Files\LANDesk\ManagementSuite\landesk\files\drivers directory.
Management Suite helps facilitate an easy download of Dell drivers in the Download updates tool. Selections
for download include drivers for many Dell makes and models of Latitude, Optiplex, Precision, and Tablet
devices. The Download updates copies the drivers to the Program
Files\LANDesk\ManagementSuite\landesk\files\drivers directory. After the download of additional drivers,
the Build Library must be updated, so the database includes the newly added drivers.
Set up the Core Server as a Preferred Server

The Core Server is setup to enable access to shares for OS Provisioning Templates, and to access the HII
Driver Repository. The Core Server is not intended to serve as the preferred server for its subnet. For that
reason, it is recommended that when you set up the Core Server as a Preferred Server, set the IP address
ranges it is to service as a subnet which does not exist in your enterprise, (i.e. 2.3.4.1 to 2.3.4.2).
To set up the Core Server as a Preferred Server do the following:

1. Click Tools > Distribution > Content replication / Preferred servers. (The Content replication tool opens
in the bottom window of the Management Suite Console.)
2. Right-click Preferred servers (Targets), and click New preferred server. (The Preferred server properties
window appears.)
a. In the Server name field type the [Core Server Name].
b. In the Description field type Core Server for OS Provisioning access.
c. In the User name field type the [Domain\Username] which provides needed access.
d. In the Password field type the password for the user name supplied.

e. In the Confirm Password field type the password for the user name supplied.
f. Click [Test credentials], to test (if desired).
g. Click IP address ranges (left pane). (The IP address ranges tab opens.)
i. Enter an address in the Starting IP address field.
ii. Enter an address in the Ending IP address field.
iii. Click [Add]. (The address range appears in the right window.)
h. Click [Save]. (The Preferred server property window closes, and the Core Server shows as a Preferred
Server.
Add Drivers to the HII Driver Repository

To Launch the HII Driver Management tool:
1. Click Tools > Distribution > HII Driver Management. (The HII Driver Management tool opens in the
bottom window of the Management Suite Console.)
2. Click the Build Library icon on the HII Driver Management toolbar.
3. Click [Save]. (This updates the repository (drivers.db3) with the drivers.
Managing Drivers in the HII Driver Repository

Managing Drivers in the HII Driver Repository entails three general tasks:
 Adding and removing drivers: Drivers must be added when new machines are purchased, and when
new operating systems are adopted. Drivers must be removed when old machines are retired, and when
old operating systems are phased out.
 Assigning drivers: Drivers can be auto-detected and assigned.
 Disabling drivers: Drivers can be disabled when they are the wrong driver for a device, causing the device
to not initiate or enable.
Adding or removing drivers

If drivers are stored in an organized hierarchy, it makes management much easier.
 Hardware Vender
o Computer Model
 Operating System
A hierarchy like this allows easy additions when adding a new computer vendor or model, and deleting
computer models or vendors when old hardware is phased out. It also allows easy additions and deletions of
Operating Systems as they are implemented and phased out. After drivers are added or removed, remember
to update the repository, using these steps:
1. Launch the HII Driver Management tool by clicking Tools > Distribution > HII Driver Management.
2. Click the Build Library icon on the HII Driver Management toolbar. (The HII Driver Repository Manager
window appears.)
3. Click [Save] (The Repository updates.)
Assigning drivers
When Plug-n-Play chooses a driver that does not work for a device, a different driver which works for the
device can be assigned. To assign a driver, perform the following steps:
2. Click the Assign icon on the HII Driver Management toolbar. (The Assign window appears.)
a. Select the Make.
b. Select the Model.

c. Select the OS.
d. Select the Architecture.
e. Select whether the chosen drive is an .inf File or a Driver Package.
f. Use the [Search] button to populate the driver location in the Search Drivers field.
g. Click [Assign]. (The driver will appear in the list.)
h. Click [Close].
Disabling drivers
When a driver being implemented does not work for a device, it can be disabled. To disable a driver, use the
following steps:
2. Click the Disable Drivers icon on the HII Management toolbar. (The Disable Drivers windows appears.)
3. Click [Search] to populate the Search Driver Library field with the path to the drivers. (The Driver Library
pane populates with the drivers.)
4. In the Driver Library pane, browse to and click on the driver to be disabled. (The Devices pane populates
with the various devices the driver and load to.)
5. Select the checkbox corresponding to the device on which you want to driver to be disabled.
6. Click the [Update and close] button.
Provisioning Settings
When provisioning templates are run on devices, a history is kept. If you want to delete the older history, select
Tools from the Operating system provisioning toolbar, and then select Provisioning Settings.
Once in Provisioning Settings, enable automatic history cleanup by selecting the automatically cleanup
provisioning history checkbox. You can set the number of days you want to keep the history.

The deletion of older history takes place when maintenance occurs.
Branding
 When provisioning templates run, a window showing the provisioning activity displays for the end-user.
Provisioning includes the ability to custom brand the provisioning display page. Company specific branding
removes doubts and concerns regarding actions taking place from the stand-point of the end-users. To
create a custom brand page, select Tools from the Operating system provisioning toolbar, then select
Branding.
When you click Branding the Default Provisioning Branding window appears. Here you can select and set
the following:
o Default title: Name the brands you create.

o Default banner: Displays what the brand looks like.
o Backgroup Color: Shows the background color
o Foreground Color: Shows the foreground color
o Browse: Takes you into file explorer to find and assign a .jpg or .png file

o Clear: Removes the banner, and takes the settings back to the original setting of the Management
Suite logo and banner.
o Preview: Displays the entire screen that the end user will see during provisioning tasks.
Self-Organizing Multicast™
Deploying very large image files can easily overwhelm the network. To effectively address this issue
Management Suite used Self-Organizing Multicast solution to address LAN and WAN bandwidth consumption,
and speed of deployment.
Targeted Multicast technology enables faster image distribution without expensive and time consuming router
reconfigurations. Multicast does NOT need to be enabled on the routers.
Targeted Multicast greatly speeds up imaging over LANs and WANs, even over slow WAN links, by
transferring the image file only ONCE to each subnet across a LAN or WAN and allowing a self-aware process
assign a device on each subnet to broadcast the files to other recipient devices.
The steps of Targeted Multicast are as follows:
5. The OS Provisioning Template is configured to use the Deploy image action with the Use Multicast
checkbox selected.
6. The OS Provisioning Template is scheduled to run on multiple devices and the task is started, OR, the
devices on subnets are PXE booted and set to receive the image via the OS Provisioning Template.
7. Each device that is to receive the image files sends a broadcast packet, asking if any other node on that
subnet has started downloading the image file.
a. The first device which is to receive the image, and is also running the LANDESK Targeted Multicast
service (tmcsvc.exe), (which is installed on each device by default as part of the Management Suite
Agent), is designated as the Multicast Domain Representative (MDR). It starts downloading the Image
file which it and other devices are to receive.
b. The other devices broadcast asking if there is an MDR, and get a response that there is. They go into
a waiting a listening mode, ready for the MDR to start broadcasting.
8. After the time designated in the Use Multicast option passes (60 seconds by default), the MDR, which has
been downloading the file begins to broadcast the file to all recipients on port 0, the Multicast port. (Hence
the name Self-Organizing Multicast.)
9. The MDR continues to download and broadcast until the entire file has been downloaded and broadcast.
Targeted Multicast Behavior

Targeted Multicast sends the full contents of a file or image (and can support up to a 30Tb file or image). The
bandwidth setting affects the speed that the blocks of data are transferred. (A block of data is the Ethernet
frame minus IDP and UDP overhead, which is about 14 to 16 bytes.) At 100% speed, all blocks would be
transferred at full speed until the entire file or image is sent. At 99% speed, 400 blocks would be sent, and a
sleep time would be invoked. The length of sleep time may vary, depending on the time it would take to send
the 400 blocks of data. At 1% speed, 10 blocks would be transferred and a sleep time would be invoked (the
sleep time would vary based upon the time it would take to send 10 blocks of data.) All other bandwidth
settings are somewhere between the 99% and 1% already described.
After the image file is sent, a response to resend requests is executed. This gives to managed devices missing
data (if the missed data is less than 10% of the file or image). If a managed device misses more that 10% of
the file or image, it receives the missing data using peer recovery. In peer recovery an address to a local

machine with the needed data is provided. Using this information, the device requesting the data can contact
the local peer and receive the missing data.
Identifiers and Imaging

When the Management Suite Agent is deployed, and the first inventory scan occurs, a unique identifier is
created. These identifiers are stored in the registry in two places:
For those managed devices with a Windows 32-bit Operating System:
 HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\Common API
 HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\Common API
For those managed devices with a Windows 64-bit Operating System:

 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LANDesk\Common API
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\LANDesk\Common API
Sometimes, for backwards compatibility support, the identifier can be found in the C:\LDIScan.cfg file. If you
want to capture an image from a device, it is suggested that the Management Suite Agent be deleted and the
identifiers be removed.
To access the article, How to Migrate to Windows 7 Using OS Provisioning – Quick Start Guide, please
go to: http://community.ivanti.com/support/docs/DOC-7443. It includes a .PDF document showing steps to
Migrate to Windows 7.
OS Provisioning Variables
To watch a video which explains use of Variables in OS Provisioning, please go to:
OS Provisioning variables allow various levels of customization. The major rule with variables is that they are
Case Sensitive. Users report that the vast majority of troubleshooting is finally narrowed down to the fact that
the variable they typed in a action did not match the case of the variable. (Please make note and save yourself
time and frustration.)
Public variables use “%” to bracket the variable name (e.g. %coreIP%). Local variables use “%%” to bracket
the variable name (e.g. %%WINDIR%%).
There are four types of variables. They are (in order of how they are applied):
 Device: Variables assigned to a specific device.
 Public: Variables which are available to all templates.
 Template: Variables that apply only to the assigned template.
 Action: Variables that apply only to a specific action.
Device Variables
To create a device variable, do the following:
1. In the All devices list, right-click a device and select Manage variables.

2. In the Name field, type the [Name] (MACaddress).
3. In the Type field, select the type.
a. String: Enter a string value
b. Database value: Enter a database ID string, such as:
Computer.Network.TCPIP.”Bound Adapter”.”Physical Address”
NOTE: Whenever there is a space, you must bracket the value with quotes.
c. Sensitive data: Enter the value to be encrypted in the database.
4. In the Value field, type the [Value] you desire.
5. Click [Save].
Public Variables
To create a Public variable do the following:
1. On the Operating system provisioning toolbar, click Tools, then click to select Public Variables.

The Public variable window appears.
2. Click [Add].
3. In the Search value field, type the [Value] you desire.
5. In the Replacement value field, type the [Value] you desire.
6. Click [OK].
Template Variables
To create a template variable, go to the template variables page within an OS Provisioning Template.
1. Click [Add]. (The User-defined variable window appears.)
2. In the Search value field, type the [Value] you desire.

4. In the Replacement value field, type the [Value] you desire.
5. Click [OK]. (The User-defined variable window closes. The variable appears in the right pane.
Action Variables
To add a specific action variable, place it directly in the Action list of the OS Provisioning Template.
1. Click Tools > Distribution > OS Provisioning. (The Operating system provisioning tool opens in the
bottom pane of the Management Suite Console.)
2. Right-click a template and click [Edit].
3. Click Action list (left pane) and select a section and select an Action in which you want to place a
variable, and click [Add]. (The Add action window appears.)
4. Click [Add]. (The User-defined variable window appears.)
a. In the Search value field, type the [Value] you desire.
b. In the Type field, select the type.
i. String: Enter a string value
ii. Database value: Enter a database ID string
iii. Sensitive data: Enter the value to be encrypted in the database.

c. In the Replacement value field, type the [Value] you desire.
5. Click [OK]. (The User-defined variable window closes. The variable appears in the Add action window.
Device Naming
To name a device during the provisioning process there are various options available:
 ldHostname variable: Include the “ldHostname” variable in the “ComputerName” field of the
SYSPREP.INF or UNATTEND.XML file called by the Inject unattend file action.
 Device Name Prompter: Use the Device Name Prompter action in the provisioning template. The
template calls the action, and the technician types the desired name which writes to a buffer, and that is
injected into the “ComputerName” field of the script, instead of the “ldHostname” variable.
 Timeout: The timeout setting brings up a prompt for the amount of time specified in the field. In this
prompt, a technician can type the name to be assigned to the device. If a name is entered, the name is
stored in a buffer that will be used (overriding the %ldHostname% variable referenced in the
Unattend.xml file invoked in the inject unattend file action of the deploy template). If no name is
entered the selected item, from the list of three in the default section, will determine the name that will
be assigned.
Unattend.xml
The unattend file which comes with the product is the script LD_Default_Unattend.xml and
references the file of the same name, found in the directory:
C:\Program Files\LANDesk\ManagementSuite\landesk\files\.
In the LD_Default_Unattend.xml file is the line:

<ComputerName>%ldHostname%</ComputerName>
This tells the program to use the public variable ldHostname, which can be in the database in the
“Computer”.“Device Name” attribute.
You can use the default, or create your own unattend.xml file and reference it in a template after you
use the install scripts function to enable it to be referenced in a template.
 LDHostName Variable: When you select the LDHostName Variable option, the program will use
either:

1. The name entered by the technician during the timeout (if a name was entered) OR
2. The name as set in the ldHostname public variable
If the unattend.xml referenced has the <ComputerName>%ldHostname%</ComputerName>

line.
 Mapped HostName: When you select the Mapped HostName option, the program will use the setting
configured in the Machine Mapping tool. (This is used if mapping a new machine being placed with a
user who is relinquishing an old machine.)
 Name Template: New in this version is an enhanced way to name devices while provisioning. The
Device Naming tool has been added, and is accessed from the operating system provisioning toolbar.
Once in the tool you can set the name by typing characters, using a variable (including truncating to
use only beginning or only ending numbers), and adding numbers which increase incrementally.

In the above example, I use the following naming convention:
 the first three characters are the city where the devices are located
 the next three characters are the room (Training Room 1)
 the next four characters are the last four characters of the MAC Address
 and the last three characters are increasingly sequential numbers

Includes
The includes page within a Provisioning template shows templates chained to the existing template. The
actions included from the chained template are greyed to show they cannot be edited from the existing
template. To edit the action one must change the source template being included.
Included by
The included by page within a Provisioning template shows templates that include the existing template. If
template “A” includes template “B”, template A shows template B in includes, while template B shows
template A in Included by.

Properties
The properties page within a Provisioning template shows the Template name, Description, Owner Name,
Boot environment, and Target OS.
History
The history page within a Provisioning template shows the history, by managed devices, which have launched
that template. The columns displayed include: Task name, Device name, Start date, Last action date, State,
Attempt number, and Template name. When a system is provisioned, all actions (and status of each action)
are recorded in the provisioning history.

XML
The XML page within a Provisioning template shows the actual xml code of the template. (In essence,
Provisioning is a graphical interface to code in xml format.) You can manually edit the file here.
The XML selection also provides the ability to export a template, whether for later import, for implementation
on another Core Server, or for sharing with others. The exported file is saved as a XTP (XML template page)
file.
The steps to export a template are as follows:

1. Double-click the provisioning template you want to export.
2. Click XML (left pane).
3. Edit code and click [Save changes].
4. Click [Export].

Options
The Options page within a Provisioning template lets you set template behavior while performing provisioning
actions. This page includes the following settings:
 Client UI Options: Settings to show on the target device while the Provisioning template runs.
o Show client UI: Select this checkbox to show the Provisioning progress window while the template
performs its actions.
 Automatically close client UI: Select this checkbox to set how long to leave the Provisioning
progress window open after the template completes its actions. (If unselected, the window will
remain open until the window is closed by someone on the target device.)
 Timeout (seconds): Type the number of seconds to leave the Provisioning progress window
open after the template completes its actions.
 Remove client provisioning folder: Select this checkbox to delete the files in the folder the Provisioning
template used to perform all of its actions once the template completes. (Examples include: files the
template copies, Software Distribution packages the template copies and installs, etc.)
 Branding: Select the branding to be shown on the devices being provisioned. Company specific branding
removes doubts and concerns regarding actions taking place from the stand-point of the end-users.
o Default title: Shows the name of the brand which is set as default.
o Default banner: Displays what the brand looks like.
o Background Color: Shows the background color

o Foreground Color: Shows the foreground color
o Browse: Takes you into file explorer to find and assign a .jpg or .png file
o Clear: Removes the banner, and takes the settings back to the original setting of the Management
Suite logo and banner.
o Preview: Displays the entire screen that the end user will see during provisioning tasks.
Operating System Provisioning Toolbar Options

The icons available on the Operating system provisioning toolbar, which have not yet been discussed in the
manual will now be presented.
Delete
The first icon on the Operating system provision toolbar is the Delete icon. Select an OS Provisioning
template, and click the delete icon to remove the template from the list.
Refresh
The second icon on the Operating system provisioning toolbar is the Refresh icon. Click on the icon to refresh
the view of the Operating system provisioning tool.
Create a Template Group
The sixth icon on the Operating system provision toolbar is the Create a template group icon. Click the
Create a template group to create a group in any folder under the Provisioning templates level. This can be
done in the My templates area, or in the Public area, if the user has rights. Creating groups for storing
templates provides ability to organize or group templates as desired.
Schedule Template
The seventh icon on the Operating system provisioning toolbar is the Schedule template icon. Use this icon to
schedule an OS Template. (For more on this, go to the Scheduled Task section.)

Import Templates
The eighth icon on the Operating system provisioning toolbar is the Import templates icon. Click the Import
templates icon to import saved XTP file templates. The tool allows browsing to find templates to import. Once
located you click [import] and the .XML file results, containing the actions of the imported file.
Help
The final icon on the Operating system provisioning toolbar is the Help icon. Clicking this icon bring up the
Management Suite documentation from the help website. The help is centralized so when you click on it, the
latest version is available to you.
OS Provisioning Template Options

When you right-click an OS Provisioning Template, options are made available. We will now go through some
of these actions.
Edit
The Edit option lets you modify the OS Provisioning Template. Since it is the option that is in bold text, it is the
default option. So if you double-click an OS Provisioning Template, the edit option will launch.

Properties
The Properties option lets you edit or change the Name, Description, Owner Name, Boot environment, and
Target OS on the OS Provisioning Template.
Clone
The Clone option creates a copy of the OS Provisioning Template. The cloned copy will have the same name
as its source, with the date and time appended to the end of the name. (Cloned copies of Locked templates
will NOT be locked as read-only.)
Condense
The Condense option creates a cloned copy of the provisioning template, but in a completely self-contained
format. If a source template includes one or more other templates, the actions introduced by included
templates are not able to be edited in the source template. But, when the template is condensed, the new,
cloned, template has all actions from included template(s), self-contained, and all actions can be edited. There
are no longer dependencies.
The use case is to have a proven template that has no other dependencies, even though the test template
included other templates. Condensing a template does not make it read-only, just self-contained.
Create disconnected template

The Create disconnected template option is to copy a template to a stand-alone USB thumb drive.
The use case is to first make the USB thumb drive bootable into WinPE using the Create Provisiong Boot
Media tool. (See the Create Provisioning Boot Media section for more information.) After that, copy the desired
template(s) to the USB thumb drive using the Create disconnected template option.
Make public
The Make public option (available if the OS Provisioning Template is in the My templates section of the
Operating system provisioning tool) copies the OS Provisioning Template to the Public section and then
deletes it from the My templates section.
Import
The Import option allows you to import .XTP (eXported TemPlate) files.
Columns
The Columns option allows you to change which columns appear, and their order of appearance, in the
Operating system provisioning right-pane. Options to include as columns are: Name, Locked, Target OS, Boot
environment, and Description.
Provisioning Alerting Ruleset

The Alerting tool contains an alert ruleset called Provisioning Ruleset. The alerts in a ruleset provide ability to
trigger actions (e.g. run a program on the Core Server, run a program on the managed device, send an e-mail,
and send an SNMP trap) based upon events. The events available in the ruleset include:
 Provisioning image complete; PXE not configured

 Provisioning shut down performed
 Provisioning task and server model mismatch

 Provisioning task began
 Provisioning task finished
 Provisioning: Boot new OS
 Provisioning: Image began
 Provisioning: Image ended
 Provisioning: Scripted install ended
 Provisioning: Scripted install started
 Provisioning: Server at boot menu
 Provisioning: Wrong Pre-boot (not booting from PXE)
When LDProvision is deployed to a device, it sends back various alerts from the device to the Core Server.
The Core Server matches the alerting event with those found in this ruleset and triggers the appropriate action
for each event.
Access the alerting window by clicking Tools > Configuration > Alerting.
Mac Provisioning
To access the article, Best Known Methods for Mac Provisioning in 9.6 SP2, go to:
Setup NetBoot on an OS X Server

In order to use Mac Provisioning you need to setup NetBoot on an OS X Server. NetBoot is how to PXEBoot in
the Mac world. The OS X Server must be either version 10.8 (Mountain Lion), 10.9 (Maverick), or 10.10
(Yosemite).
The steps to setup NetBoot on the OS X Server are as follows:

1. Enable NetInstall on the OS X Server.
2. Set the NetBoot Storage Settings to point to the proper location on the OS X Server. All NetBoot images
should be stored at /Library/NetBoot/NetbootSP0.
3. Set the MANAGEMENT SUITE Core Server to use a PXE Representative to provision Mac Devices.
4. Create a NetBoot Image.
a. Add wildcard “.” for the NetBoot Image to show up as a PXE Representative.
b. Install the Mac Agent on the Mac OS X Server.
Manage NetBoot Image Mappings

To set the MANAGEMENT SUITE Core Server to use a PXE Representative to provision Mac Device (step 3
above), select the Preboot icon in the Operating system provisioning toolbar, and select Manage NetBoot
Image Mappings.

Selecting Manage NetBoot Image Mappings brings up the Mac NetBoot Image Mappings window.
Here you enter the path to NetBoot image (.nbi) files. You can also select which NetBoot image you want to be
the default.
Mac Provisioning Actions

When you create a provisioning template, if you select NetBoot as the Boot environment, only the Mac
Provisioning actions will be available. The Mac Provisioning actions are:
Action System Pre-OS OS Post-OS System

migration installation installation installation configuration
Capture an X
Image
Capture Profile X
Change Agent X X
Settings
Configure Agent X
Copy file X X X X X
Create directory X X X X X
Delete file X X X X X
Deploy an Image X
Deploy Profile X

Device Name X X X X X
Prompter
Distribute X
Software
Download file X X X X X
Execute file X X X X X
Map/Unmap X X X X X
drive
Mount Iso X X X X X
Partition X X X
Reboot X X X X X
/shutdown
Unzip file X X X X X
Wait X X X X X
Capture Image (available only in the OS installation section)

Use this action to capture an image from a target device. The capture image action uses preferred servers to
authenticate to the shares. This is set in the Content Replication / Preferred Servers tool. A Mac OS X
Server has to be set as a Preferred Server. The User name and Password fields in the Core Server’s Preferred
server properties are used to access the shares. The options available for this action include:
 Specify the path to save the image file, including the name of the image file: To enter the location to
capture and store the image file. Either smb://Server/SharePoint/ImageFile.dmg OR
afp://Server/SharePoint/ImageFile.dmg format can be entered into this field.
 Mac Image: Select Mac Image.
 Validate: Click the [Validate] button to populate the Command-line parameters field with the data
provided in the other fields.
Change Agent Settings (available in system migration, and system configuration

sections)
Use this action to change the agent settings. You can deploy an agent with settings of the inventory scan, the
patch scan, and other actions deferred until much later, so as to not interfere with other actions the template
may still need to run. Then, after all other actions have run, set the agent setting so inventory scan, the patch
scan and other actions occur as regularly as needed.
The settings can be configured, edited, and set, for all agent settings within this action.
Capture Profile (available only in the system migration section)

Use this action to capture a profile on a target device.

and Password fields in the Core Server’s Preferred server properties are used to access the shares.
When saving profiles, you can specify a full filename, or you can use unique identifiers to create the file name
to store the profile.
The Mac version of capture profile is limited to:
 Core Certificate
 Machine Name
 How Network Adapter Interfaces are configured
 MANAGEMENT SUITE Configuration
The fields that can be selected in this action are a follows:
 Path for saved profile: To specify the location to store the profile when it is captured. The format can be
smb://server/sharepoint or afp://server/sharepoint.
 Specify full filename instead of using variables: Select this radio box if you want to disable the filename
unique identifiers options. Selecting this will require the filename to be specified in the Path for saved
profile field.
 File name unique identifiers: Select any combination of the computer name, MAC address, and serial
number to create the filename of each profile.
Configure Agent (available only in the system configuration section)

Use this action to install the Management Suite Agent onto the target device. This action can be the first action
after a reboot following Operating System install actions. Configurations are added to the drop-down menu as
created in the Agent Configuration tool.

and Password fields in the Core Server’s Preferred server properties are used to access the share to the agent
configuration files.
 Configuration name: Select which Agent Configuration to deploy in the action.
 Reboot if required: Will set a reboot to occur after the agent is installed.
Deploy an Image (available only in the OS installation section)

Use this action to deploy an image from a target device. The capture image action uses preferred servers to
authenticate to the shares. This is set in the Content Replication / Preferred Servers tool. A Mac OS X
Server has to be set as a Preferred Server. The User name and Password fields in the Core Server’s Preferred
server properties are used to access the shares. The options available for this action include:
 Specify the path to save the image file, including the name of the image file: This is to define the
smb://Server/Share/ImageFile.dmg or afp://Server/Share/ImageFile.dmg to capture the image.
 Mac Image: Select Mac Image.
 Validate: Click the [Validate] button to populate the Command-line parameters field with the data
provided in the other fields.
Distribute Software (available only in the system configuration section)

Use this action to distribute software applications created in the Distribution Packages tool to the device being
provisioned. You must place the Map drive action prior to the Distribute software action in order to authenticate
to the share. Also, the agent configuration action must be placed prior to the Distribute software action.
 Available distribution packages: This option presents all created packages in a drop-down menu.
o Type filter: This presents options to choose from All packages or limit those presented by Package
Type.
o Search: This presents options to search for packages by name. You can search in My packages or
Public packages. It includes a [Next] button if you type a package name.
Mount Iso (available in all sections)

Use this action to mount an iso image. The following fields are presents:
 Image name and path: Enter the \\server\share\file.iso information.
 Mount point: Enter the desired mount point.
Partition (available in pre-OS installation, OS installation, and post-OS

installation sections)
 Action type: Use this field to select a partition action. Option include: create a partition, remove all
partitions, format a partition, mount a partition, unmount a partition, or resize a partition. NOTE: The Boot
environment and target OS must be set prior to executing this action.
 Disk ID: Type the disk ID (Windows: disk number) or (Linux: name of the disk).
 Partitions: Use this field to select and name partitions.
You can specify a size in MB or a percentage of the disk. Be sure the amount of disk space exists. This
action will overwrite anything that currently exists. If you do not specify a size on a partition, (this can only
be left empty on the last partition) the remainder of the disk will be assigned the last partition.
All other action types were defined previously.
Note: Windows has a Distribute software action which is NOT available as a Mac action. The Execute file
action can be used to run a shell script to install applications.

Troubleshooting
For errors during the PXE boot process, access the article, How to troubleshoot PXE boot (OS
PROVISIONING), at: http://community.ivanti.com/support/docs/DOC-8358.
WinPE log files are found in the X:\ldprovision folder. Since the X: drive is a RAMDisk, it self-cleans when the
reboot occurs.
Windows log files are found is the C:\ldprovisioning and System Temp (C:\Windows\Temp) directories. There
is a setting in the provisioning template “Remove client provisioning folder” which will delete
C:\ldprovisioning after the template runs.
When a provisioning task fails, the user can:

1. Open the Scheduled tasks tool, click to expand the failed task.
2. Click to highlight Failed. (The failed device appears in the right pane.)
3. Right-click the failed device and click View provisioning history. (The Provisioning history window
appears.
From here, you can expand tasks and find what succeeded and what failed. Information can be seen in the
Results, Action properties, and Parameters tabs.
Gathering Server Side and Client Side Log Files

For troubleshooting purposes gathering log files, either from the Core Server or the Managed Device,
facilitates finding what step is failing in the process. To download log files, from either the Core Server or the
Managed device, do the following:
6. In the Console, locate a managed device from which you want to locate and download the log files. (This
can be in either the Network View or in the Scheduled tasks tool.)
7. Right-click on the device, and click Diagnostics. (The Diagnostics – Client Name window appears.)
8. Click to select Logs on the toolbar.
9. Click to select either Client or Core, depending on which log file source you want.
10. Choose the specific log file you want. It will download the file and bring it up for you.

Check for Understanding concerning Provisioning
1. What version of WinPE is used in Management Suite 2016, and what are the implications of having this
version?
2. How does the additional feature of PXE Services being managed in Self-Electing Subnet Services help in
the Management Suite environment, and do you configure the feature?
3. In hardware independent imaging what new feature is introduced in Management Suite 2016, how does
this feature help, and how do you configure the feature?
4. What is conditional branching in a provisioning template, and how is this feature helpful?
5. What client-side branding changes are introduced in Management Suite 2016, and how is this helpful?
6. How is customization feature in the product mapping action of a provisioning template helpful, and how do
you use it?
7. How is the device naming feature used in provisioning, and what is hierarchy defined in the algorithm?
8. How is the change agent setting action in provisioning helpful, and how do you use it?

Patch Management
Module Objectives
 Cite business use cases for Patch Management

 List steps to implement Patch Management
 Describe Types of Content which can be Downloaded from Subscription Servers
 Download Content from Subscription Servers
 Disable Replaced Rules
 Set Definitions to be Scanned
 Configure Distribution and Patch Agent settings
 Scan Managed Devices to identify vulnerabilities they have
 Identify the vulnerabilities which need remediation
 Download remediation fixes for vulnerabilities found in the enterprise
 Deploy remediation fixes to managed devices
 Run reports showing vulnerability status
 Utilize the Toolbar in the Patch Management Tool
 Utilize Rollout projects to Automate Patch Deployment

Patch Management Use Case Scenario
Nearly every computer, if not every computer in the enterprise needs regular security updates. Failure to do so
introduces exposure to substantial security risk. The monumental task of assuring patch levels for each device
throughout the enterprise is made surprisingly manageable with Ivanti Patch Manager, as a part of Ivanti
Management Suite (Powered by Landesk).
Steps to Implementing Patch Management

1. Download patch vulnerability definitions from subscription servers. (Also, create custom definitions, if
desired.)
2. Disable replaced rules.
3. Determine which of the new definitions you want to be implemented on managed devices.
4. Create and place a Distribution and Patch agent setting which determines actions and functionality while
scanning.
5. Scan the managed devices to identify the vulnerabilities for which they are susceptible.
6. View the vulnerabilities which need remediation and on which devices.
7. Download the remediation fixes for patch vulnerabilities.
8. Deploy the remediation fixes to the managed devices which need them.
9. Run appropriate reports, showing vulnerabilities, remediations, etc.
10. Repeat as needed, when new vulnerability definitions are downloaded from subscription servers.
For a document on How to start using Patch Manager in LANDESK® Management Suite 9.5 please go to:
Downloadable Content from Subscription Servers

Types
Ivanti Management Suite (Powered by Landesk) when combined with a Ivanti Patch Management subscription
agreement allows downloading a variety of content types. These content types include:
 Antivirus: Scans for malicious software, and updated pattern files from numerous vendors.
 Blocked Applications: Denies the launch of defined and prohibited applications.
 Custom Definition: Allows detection and remediation of custom defined definitions.
 Driver: Provides device driver updates.
 LANDESK Update: Verifies the latest Ivanti is installed.
 Security Threat: Seeks Microsoft Operating System configuration risks and exposures: including firewall
detection and configuration. Also this can find which Apple Macintosh devices do not have Apple’s disk
encryption, FileVault, enabled.
 Software Update: Verifies installation of updates to Intel, Dell and ThinkVantage software products.
 Spyware: Scans and removes spyware, including real-time malware.
 Vulnerability: Seeks Microsoft Operating Systems and applications (both for known platforms and specific
applications)
(Note: Without the Ivanti Patch Management subscription addition, a small subset of content types is
downloadable.)
Key Features of Download Content Types

Antivirus: Provides ability to assure that:

 An Antivirus solution (listed in the table below) is installed.
Antivirus Product Windows Macintosh

Avast Antivirus X
AVG Antivirus X
Avira Antivirus X
BitDefender Antivirus X
BullGuard Antivirus X
CA Total Defense Antivirus X
eScan Antivirus X
ESET NOD32 Antivirus X
eTrust Antivirus X
Gdata Antivirus X
Kaspersky Antivirus X X
LANDESK Antivirus X X
McAfee Antivirus X X
Microsoft Forefront Antivirus X
Microsoft Windows Defender X
Panda Antivirus X
Shavlik Antivirus X
Sophos Antivirus X X
Symantec Antivirus X X
Trend Micro Antivirus X
VIPRE Antivirus X
 real-time scanning/repair is enabled
 the virus scanner pattern file is up to date
 there has been a recent virus scan
Blocked Applications: Provides ability to block applications from running on managed devices. The
download content tool provides a list of nearly 7,000 files that can be blocked. The files are of various types
including: adult, adult content dialer, file sharing, gaming, instant messaging, Javams virus,
keylogging/monitoring, media player, media playing application, potentially malicious, screen saver,
spyware/adware, TeamViewer - remote access, virus, and web page hijacker.
To place the applications to be blocked, the patch scanner, vulscan.exe, runs on the managed devices. The
executable names are written to the registry, and softmon.exe blocks them from running. The registry location
where the blocked executable files are blocked is:
HKEY_LOCAL_MACHINE\SOFTWARE\[WOW6432Node\landesk\managementsuite\WinClient\
SoftwareMonitoring\FTD

The files are blocked by the name per the file header, thereby blocking a file even if it is renamed.
Custom Definition: Provides ability to search for custom definitions you define yourself. The definitions
can be defined by:
 Affected Platforms
 Affected Products
 Query
 File existence of non-existence
 Registry key, value, or data (limited to HKLM)
 Custom Script
The patch scanner, vulscan.exe, runs on the managed devices and reports devices vulnerable, as defined.
These can be acted upon by a script, or command while being scanned, or via scheduled task or scheduled
policy.
Driver: Provides ability to search for driver update definitions. If managed devices are found to be lacking
driver updates, they can be downloaded and run on the devices, updating them. Updates can be applied via
patch scan, scheduled task, or scheduled policy.
LANDESK Update: Provides ability to search for updates of files used by Management Suite. If managed
devices need LANDESK updates, the updates can be downloaded and run on devices via scan, scheduled
task, or scheduled policy.
There is ability to download Ivanti Data Analytics Updates, and LANDESK File Reputation Updates (used by
Application Control.
Security Threat: Provides ability to search for defined security threats on managed devices. Generally,
these usually do not require downloads for remediation, but instead require configuration changes to be made.
Security threat definitions can be downloaded for the follow OS types:

 Macintosh: defined by APPLE
 Windows: definitions outlined by:
o Microsoft
o Federal Information Security Management Act
o Internet Security Benchmarks
o Microsoft Baseline Security Analyzer (MBSA) Security Configuration Check
o National Institute of Standards and Technology (NIST)
o National Security Agency (NSA)
o Payment Card Industry(PCI) Security Standards Council
o SANS (officially the Escal Institute of Advanced Technologies)
 Linux/Unix:
o HP-UX
o Red Hat Linux
o Sun Solaris
o SUSE Linux
Software Update: Provides ability to update software on Macintosh and Windows. Windows software
updates includes searching for devices utilizing ThinkVantage™ Technologies (TVTs) defined by Lenovo. The
specific updates sought for include: Access Connections, Client Security Solutions, and Rescue and Recovery.

Spyware: Includes definitions by LavaSoft®, the manufacturer of AdAware™. When the patch scanner,
vulscan.exe, runs, it can clean and remove spyware as it scans. The log created will list the spyware removed
on individual devices.
Vulnerability: Includes seeking for vulnerabilities as defined, and downloading repaired versions of
applications on managed devices. These remediations can be run during scan, scheduled task, or scheduled
policy.
Vulnerability definitions can be downloaded for the follow OS types:

 Macintosh: defined by APPLE
 Windows: definitions by Microsoft
 Linux/Unix: definitions for:
o CENTOS Linux
o HP-UX
o Red Hat Linux
o Sun Solaris
o SUSE Linux
o SUSE Linux ES
Architecture
The patch scanner, VULSCAN.EXE, runs on the managed device. The Distribution and Patch Agent
settings, which the scanner uses, are configured in the Management Suite Console and assigned to managed
devices. Throughout the scanning process, there is communication between the scanner and Core Server.
This communication gives the scanner instructions, on the managed device side, and updates the detected
vulnerabilities on the Core Server side.
Step 1: Download Definitions

The first defined step to implement patch management is, “Download patch vulnerability definitions from
subscription servers.”
Under the Tools > Security and Compliance menu is the Patch and Compliance tool. The first selection in
the menu is [Download Updates].
The Download updates tool provides ability to choose numerous download settings, including: what types of
definitions to download, when and where to download the remediation patches, and how to group patch
definitions.

Buttons which are available on ALL of the Download Updates tabs include:
 Download now: To select to initiate Download updates immediately.
 Schedule download: To create a Scheduled task to automatically initiate Download updates. When the
task is scheduled the selections should be what you want them to be when the downloads occur.
 View log: To view the vaminer.log file which logs Download updates. Features here include setting the
location of the log file, and setting the level of logging to standard or detailed with a checkbox selection.
 Apply: Sets the Download updates current selections so the next time the tool is opened it will have the
same selections chosen.
 Close: Closes the Download updates window.
 Help: Opens the on-line help, which offers a context aware detailed explanation of the tools.
Updates tab
The Updates tab grants access to set the following options:
Select update source site: Allows selecting one of three source sites Ivanti provides world-wide. There are
two servers which feed the three world-wide servers. One updates and the top and bottom of each hour, which
the other updates at quarter past and quarter to each hour.
Definition types: Choose from various items for Linux, Macintosh, and Windows.

Languages: Choose from 20 different language selections.
Download patches: Lets you select to download patches (remediations) when Download updates runs. It
offers two selections:
 For detected definitions only: Downloads only patch remediations for Detected items.
 For all download definitions (This may take a long time): Downloads ALL patch remediations for each
and every downloaded definition.
Definition grouping: Lets you select whether to have downloaded definitions go into the Scan group, or the
Unassigned group. The checkbox Put new definitions in “Unassigned group”, is for an all or nothing
approach. If selected all new definitions are placed in the Unassigned group. If unselected all new definitions
are placed in the Scan group.
If you want more select ability to assign to groups, use the Definition group settings button. This allows to
select by Definition Type, Severity, or comparison to assign group membership. Group membership can not
only select the Scan, or Unassigned, groups but also create a Custom group in which to place new definitions.
Proxy settings tab

Allows for setting the addresses, ports, credentials, etc. which the Core Server which needs to access the
internet to download definitions and remediations. Some sites do not need to set Proxy settings.
Patch location tab

Allows for setting where the remediation patches will be placed, whether obtained using the Download updates
tool or downloading singly by definition. There are settings that allow for grouping patches in subfolders by
language and vendor. A great feature is the Patch Cleanup setting to decrease storage space for remediation
patches which are no longer required.

LANDESK Antivirus tab
Provides ability to download updated pattern files and make them available to managed devices. It Also
provides setting virus definition backups.
Content tab
Provides ability to select a checkbox to Verify definition signatures/hashes before downloading. When
selected, any definitions that do not have valid SHA256 hash will not be downloaded. Also, any lists of
definitions that do not have a valid signature will not be processed. The download process form will show any
download failures due to invalid or missing signatures or hashes.
Import/export tab
Allows ability to do the following:
 Import settings from file: Lets you select and import a file to apply settings for Download updates.
 Export setting to file: Lets you create and save a file with Download updates settings, for someone else
to import.
 Copy settings to another core: Lets you copy custom content from a core server to a selected destination
core server. Content can include configurations, scheduled tasks, software packages, and patch content.

Step 2: Disable replaced rules
It does not make sense to apply a patch that has been completely replaced by a newer patch. Therefore, best
practice is to disable rules whose patches have been superceded by a later patch.
To accomplish this step we can implement the disable replaced rules feature. On the Patch and Compliance
toolbar is the Disable replaced rules icon.
When run, the rules that have been completely replaced by a new rule (superceded) will be disabled. Only
rules that are replaced by an enabled definition will be disabled.
For more information, please see the Ivanti community article, “How To: Use the Disable Replaced Rules
Tool in Security and Compliance Manager - Video” which can be found at:

When the Disable replaced rules icon is clicked, the Disable replaced rules window appears.
When this is utilized, the rules that have been replaced are disabled. One of the columns in the details of the
Patch and Compliance tool is Rules disabled. This column indicates those rules which have been disabled.
Designations in this field include:
 All: Each of the rules in the vulnerability has been disabled.
 Part: Some, but not all, of the rules in the vulnerability have been disabled.
 None: None of the rules in the vulnerability have been disabled.
When a rule has been disabled, the icon on the rule changes to have a red x.

The Replacements tab shows the replacement information.
Step 3: Determine Definitions to be scanned

The third defined step to implement patch management is, “Determine which of the new definitions you want to
be implemented on managed devices.” (This is often referred to as grouping definitions.) The definitions to be
scanned for should be in the “Scan” group. This can be done in four ways.
1. Have newly downloaded definitions placed in the scan group.
2. Configure a subset of newly downloaded definitions to be placed in the scan group.
3. Manually drag and drop the definitions in the scan group.
4. Create custom groups, and set the configuration to scan for definitions in those groups.

Setting newly downloaded definition for placement in the scan group
Through the Definition grouping setting in Download Updates multiple settings for newly downloaded
definitions can be accomplished.
To have newly downloaded definitions placed in the Scan group, simply leave the selection Put new
definitions in “Unassigned” group unchecked.
To configure a subset of newly downloaded definitions to be placed in the scan group, click the [Definition
group settings] box and create a configuration. Again, there is a [help] button which brings detailed
explanations to make the desired settings.
To manually drag and drop the definitions in the scan group, open the Patch and Compliance tool, assure the
appropriate Type selection is chosen, and drag definitions into the Scan group.

To create custom groups, open the Patch and Compliance tool, expand Groups and create a custom group
name. Then, drag and drop the desired definitions into the custom group just created. A configuration can then
be created to scan for the custom group.
Step 4: Create a Distribution and Patch Agent setting to use during a

Patch scan
The fourth defined step to implement patch management is, “Create a Distribution and Patch Agent Setting
which determines actions and functionality while scanning.” There are four places where you can access ability
to configure a Distribution and Patch Agent setting:
 Agent Configuration: using the Distribution and Patch tab
 Agent settings: using the Distribution and Patch setting
 Patch and Compliance: using Configure Settings > Agent settings
 Patch and Compliance: creating a scan task and selecting the Agent settings

To build an Agent setting in the Agent configuration tool, go to Distribution and Patch tab.
To build an Agent setting in the Agent settings tool, you also go to the Distribution and Patch tab.

To build an Agent setting in the Patch and Compliance tool, select Agent settings.
To build an Agent setting in Agent settings > Create a task > Change settings, select the Change settings tab,
and select [Configure].
Distribution and Patch settings

The settings available in Distribution and Patch affect how the managed devices run the Distribution and Patch
scans.

General settings tab
In the General settings tab the Name of the setting is designated. There is also an option to make the setting
the default.
Network settings tab

In the Network settings the following options can be set:
 Preferred server / Peer download options
o Attempt peer download (download files from other clients on the same subnet)
o Attempt preferred server (automatically redirect to the closest preferred server)
o Allow source (download from original location if files were not found in other locations)
o Use multicast (For more information see the Self-Organized Multicast section.)
 Bandwidth used from core or preferred server (WAN): Set between 1 and 100 percent.
 Bandwidth used peer-to-peer (Local): Set between 1 and 100 percent.
 Task options – Send detailed task status: Select whether to send detailed task status.
Policy sync schedule tab

 Policy sync schedule: Select how often to run PolicySync.exe to see if there are outstanding tasks (failed
pushes or outstanding policies) to run.
o When user logs in: Select whether to run when the user logs in (with a configurable maximum delay).
o When I address changes: Select whether to run when the IP address changes.
o Schedule-driven: Select how often to run in an on-going schedule.

Notification tab
In the Notification tab are settings as to whether to notify the end user on a managed device when software or
patches are being downloaded, installed or removed, whether the user can defer or cancel the action, and
whether to have progress be shown or silent.
User message tab

In the User message tab, you can type the user message you want to appear when software or patches are
being deployed to a managed device.
Distribution-only settings, Offline, and logged off user options tabs

These tabs are settings for Software Distribution, and will not be covered in the Patch section.
Patch-only settings tab

The options in the Patch-only settings affect the patch portion of the settings and include:
 When no reboot is required:
o Require end user input before closing (This can cause scheduled tasks to timeout).
o Close after timeout: With a timeout set in minutes (default setting and set to 1 minute).
 Alternate core: Whether to Communicate with an alternate Core Server.
 When installed via Cloud Services Appliance (CSA): Options as to whether to download patches or not,
and if so from where.
 CPU utilization when scanning: How much resource to use when vulscan runs on the managed device.
 Schedule task log: Set how verbose to log the Patch actions.
Do not disturb tab

Set whether to hide scan progress dialogs and/or defer any install or remove actions if certain processes are
running (such as using Microsoft PowerPoint to give a presentation). There are also settings for Legacy Mac
agent user interruption settings.
Scan options tab

Set whether to Scan (and possibly repair) a group of vulnerabilities, what download types to scan (and possible
repair), and whether to enable autofix when scanning.
Schedule tab
Schedule when a Patch Scan will routinely run (set for each Distribution and Patch setting.
Frequent scan tab

Set whether to enable scan and repair actions more frequently.
Pilot configuration tab

Set whether to periodically scan and repair definitions in a specific custom group.
Spyware scanning tab

Set whether to override Agent Configuration settings with Distribution and Patch settings regarding spyware
blocking being enabled, and if so whether to notify the end-user if spyware blocking has acted on the managed
device.

Install/remove options tab
Set whether to let an install or remove action to occur if a Reboot is already pending. (It is recommended that
you select the Reboot is already pending checkbox. This can be very helpful!)
Continuation tab
Set whether to automatically continue install or remove actions after prerequisites are met. Possible
prerequisites include: completing a required reboot, installing prerequisite patches, or entering the next
maintenance window.
Maintenance window tab

Set whether to defer any install, remove, or reboot actions until the specified maintenance window. File
downloads are allowed outside the maintenance window, but NOT install, remove, or reboot actions. (If window
duration is exceeded while installing or removing a patch, the current action will complete but additional actions
will be queued to wait.)
Pre-repair script tab

Specify a script to run before installing or uninstalling one of more patches.
Post-repair script tab

Specify a script to run after installing or uninstalling one of more patches.
MSI information tab

Specify a share holding an original software package MSI file, as well as credentials to access the share
location. Also, set credentials to use when running patch install/uninstall.
Branding
Specify whether to use a customized window caption when Patch scanning occurs, if the scanning is not run
silently.
Step 5: Scan managed devices to determine existing vulnerabilities

The fifth defined step to implement patch management is, “Scan the managed devices to identify the
vulnerabilities for which they are susceptible.” This means the patch scan (VULSCAN.EXE) must be run on
each managed device. There are two ways this can be done. The first way is to have the managed device
perform the scan periodically and automatically through a setting in the Distribution and Patch Agent setting.
The second way to launch a patch scan on a managed device is through scheduling a scan from the Console.
Setting the Patch Scan in the Distribution and Patch Agent setting
To set a periodic and automatic patch scan in the Distribution and Patch Agent setting, Access the Distribution
and Patch Agent setting, and go to the Policy sync schedule tab. From here the configuration opens and you
can set how often to launch the policy sync schedule which will launch the patch scan.

This adds a setting on the local scheduler when the agent is deployed to the managed device. The task can be
viewed in the Console in the Inventory of the managed node, in LANDESK Management > Local Scheduler
> Scheduled Tasks. The task can be viewed on the managed device by launching CMD and in the command
window running C:\Program Files\LANDesk\LDClient\localsch.exe /tasks >more.
Scheduling a Patch Scan to occur on a Managed Device

To schedule Patch Scan to occur on a Managed Device do the following:
2. Click Tools > Security and Compliance > Patch and compliance. (The Patch and Compliance tool
opens at the bottom of the Console.)
3. Click the Create a task icon.
4. Click Security scan. (The Patch and Compliance – scan task window appears.)
5. Name the task in the Name field
6. Click to select Agent settings.
7. Click the Settings cell to the right of Distribution and patch, then select the Distribution and Patch setting
you want to be run on the managed device(s).
(Note: You can edit the configuration setting, or create a new setting by selecting the [Edit] or [Configure]
box.)
8. Click [Save]. The task or policy will appear in the Scheduled tasks tool.
9. Drag and Drop the devices, and/or device group, and/or query, and/or LDAP object, to scan, and start the
task.
Step 6: Viewing the Vulnerabilities which need Remediation

The sixth defined step to implement patch management is, “View the vulnerabilities which need remediation
and on which devices.” The vulnerabilities needing remediation are shown in Patch and Compliance tool in
the Detected section. Any item listed in the detected section can be right-clicked opening a variety of options

for each item. One option is Affected computers, which shows all managed devices which have this specific
vulnerability.
When each device which is vulnerable is remediated, this specific vulnerability no will no longer appear in the
Detected section. If the specific vulnerability is removed from the Scan group, it is automatically removed from
the Detected section as well.
Step 7: Downloading Remediations for Vulnerabilities

The seventh defined step to implement patch management is, “Download the remediation fixes for patch
vulnerabilities.” The ideal way to do this is to set this action to happen automatically, although this can be done
manually as well.
Setting Remediations to Download Automatically

To set the download of remediations (fixes) to occur automatically, set Download updates to obtain them. The
steps to do this are as follows:
3. Click the Download updates icon.
(The Download updates window appears.)

4. In the Download patches field, click the box to select Download patches for definitions selected above.
5. Click to select for detected definitions only.
6. Click [Schedule download]. (The Scheduled update information window appears.)
7. Click [OK]. (The Schedule task window appears.)
8. Click Schedule task, and select when to have all updates and remediations to automatically download,
and click [Save]. (The task will appear in the Scheduled Tasks tool.)
Downloading Remediations Manually

To download remediations (fixes) manually, do the following:
3. In the Patch and Compliance window, click Detected. (The vulnerabilities which have been detected as
vulnerable appear in the right window.)
4. Right-click the vulnerability which you want to download, and click Download associated patches. (The
Download Associated Patches window appears.)
5. Click to select Show all associated patches.
6. Click to select all of the remediations you want to download, as well as if you want to include prerequisites
and/or dependencies, and click [Download].
7. The Downloading Patches window appears and the patches are shown to be downloading. (They will be
stored in the location specified in the Download Updates tool on the Patch location tab.)
8. Click [Close].

Step 8: Deploying Remediations
The eighth defined step to implement patch management is, “Deploy the remediation fixes to the managed
devices which need them.”
Minimizing bandwidth consumption

When deploying remediations, Management Suite always minimizes the bandwidth required to deploy patches.
The download hierarchy which puts this objective in place includes:
 Attempt peer download (download files from other clients on the same subnet)
 Attempt preferred server (automatically redirect to the closest preferred server)
 Allow source (download from original location if files were not found in other locations)
 Use multicast: Used Targeted Multicast
Self-Organizing Multicast
Deploying patches, some of which are very large, can easily overwhelm the network. To effectively address
this issue Management Suite used its patented Self-Organizing Multicast solution to address LAN and WAN
bandwidth consumption, and speed of deployment.
Targeted Multicast technology enables faster image distribution without expensive and time consuming router
reconfigurations. Multicast does NOT need to be enabled on the routers.
Targeted Multicast greatly speeds up imaging over LANs and WANs, even over slow WAN links, by
transferring the image file only ONCE to each subnet across a LAN or WAN and allowing a self-aware process
assign a device on each subnet to broadcast the files to other recipient devices.
The steps of Targeted Multicast are as follows:
10. Patch remediation is invoked in one of various methods.

11. The Distribution and Patch setting is set to Use multicast.
12. Each device that is to receive the patch(es) sends a broadcast packet, asking if any other node on that
subnet has started downloading the patch(es).
a. The first device to apply the patch(es), and is also running the LANDESK Targeted Multicast service
(tmcsvc.exe), (which is installed on each device by default as part of the Management Suite Agent), is
designated as the Multicast Domain Representative (MDR). It starts downloading the patch(es) it and
other devices are to receive.
b. The other devices broadcast asking if there is an MDR, and get a response that there is. They go into
a waiting a listening mode, ready for the MDR to start broadcasting.
13. After the time designated in the Use Multicast option passes (1 minute by default), the MDR, which has
been downloading the patch(es) begins to broadcast the patch(es) to all recipients on port 0, the Multicast
port. (Hence the name Self-Organizing Multicast.)
14. The MDR continues to download and broadcast until the patch(es) file-by-file have been downloaded and
broadcast.
Targeted Multicast Behavior

Targeted Multicast sends the full contents of a file. The bandwidth setting affects the speed that the blocks of
data are transferred. (A block of data is the Ethernet frame minus IDP and UDP overhead, which is about 14 to
16 bytes.) At 100% speed, all blocks would be transferred at full speed until the entire file or image is sent. At
99% speed, 400 blocks would be sent, and a sleep time would be invoked. The length of sleep time may vary,

depending on the time it would take to send the 400 blocks of data. At 1% speed, 10 blocks would be
transferred and a sleep time would be invoked (the sleep time would vary based upon the time it would take to
send 10 blocks of data.) All other bandwidth settings are somewhere between the 99% and 1% already
described.
After the image file is sent, a response to resend requests is executed. This gives to managed devices missing
data (if the missed data is less than 10% of the file or image). If a managed device misses more that 10% of
the file or image, it receives the missing data using peer recovery. In peer recovery an address to a local
machine with the needed data is provided. Using this information the device requesting the data can contact
the local peer and receive the missing data.
Deploying the remediation Patches

Deploying the remediation patches can be done in the following ways:
1. Schedule a task to deploy a patch (or group of patches).
2. Have the patch (or multiple patches) fix when the patch scan occurs, using AUTOFIX.
Schedule a TASK to deploy a Remediation

The steps to schedule a task to deploy a fix to necessary managed devices are as follows:
3. In the Patch and Compliance window, click Detected. (The vulnerabilities which have been detected as
vulnerable appear in the right window.)
4. Right-click the vulnerability which you want to repair, and click Repair. (The Patch and Compliance – repair
task window appears.)
5. Select an option from a drop-down list of which targets to add in the Add targets field.
6. Click to select Agent settings, and select the Distribution and Patch Agent setting in the Settings cell to
the right of Distribution and patch.
7. Click to select Definitions, to choose definitions to repair, and prerequisites, and/or dependents, and click
[Save]. (The Schedule task window appears.)
8. The Repair task will appear in the Schedule tasks tool.
9. Right-click the Repair task, and click Start now. (The task will determine which devices need the repair,
and launch the fix on them.)
(NOTE: The Distribution and Patch Agent settings has options to download the patch(es) from local peers,
and/or Preferred Servers, to reduce bandwidth on WAN links.)
Using AUTOFIX to deploy a Remediation

Autofix is a setting that allows a managed device to scan for vulnerabilities, and then download a remediation
and apply the patch to fix the vulnerability right then.
To use AUTOFIX to repair, there are three settings that need to be in place.
1. The Global settings in the Standard LANDESK agent tab of the Agent Configuration.
2. The Scan options in the Distribution and Patch Agent setting.
3. The Autofix option setting on the vulnerability.
Each of the three items must be in place. If any of these is not set, Autofix will not occur.

The Global settings in the Standard LANDESK agent tab of the Agent
Configuration
The Never autofix box must NOT be selected.
This allows a setting (such as for Servers) where devices with a setting Never Autofix checked can avoid any
automatic repairs, while at the same time, managed devices without the setting can automatically repair when
scanning.

The Scan options in the Scan and Repair Setting
The Enable autofix option must be selected in the Scan options tab of the Distribution and Patch Agent
setting.
The AUTOFIX option setting on the vulnerability

To enable the AUTOFIX option on a vulnerability, select the vulnerability, right-click and select Autofix. This
will present options to autofix all devices (global autofix), or a subset of devices (autofix for all scopes).
Uninstall (rollback) a patch

You can uninstall (rollback) patches that have been deployed to managed devices. The use case is to remove
unexpected conflicts or undesired results. The goal is to store the managed device to its original state.
Some patches do not have an uninstall, and some have only a Manual install and uninstall.
For those which can be uninstalled or rolled back, the steps to uninstall are:

To uninstall (roll back) a patch:
1. Locate the rule within the vulnerability you want to uninstall. right-click one or more rules, and then click
Uninstall.
2. In the Name field, use the name already offered, or type what you want to name the uninstall task.
3. In the Add targets field, select Add all computer with this patch from the drop-down list.
4. Select any and all other items you want to occur within the task, and click [Save]. (The task is created, and
depending on you selections the task launches.)
5. If the task does not launch with the selections you chose, add any devices to the task, and launch the task.
If a patch installation failed, you must first clear the install status information before attempting to install the
patch again. You can clear the install (repair) status for the selected device by clicking Clear on the Security
and Patch Information dialog box. You can also clear the patch install status by vulnerability.
To remove patch files permanently, you must delete them from the patch repository, which is set on the Patch
location tab of the Download updates tool.
Step 9: Run Reports showing Vulnerability Status

The ninth defined step to implement patch management is, “Run appropriate reports, showing vulnerabilities,
remediations, etc.” There are many standard reports available to be run concerning all security, including
vulnerabilities. Under Standard Reports > Security are reports for: Antivirus, Blocked applications,
Compliance, Custom definitions, Host intrusion prevention, LANDESK updates, Security threats, Spyware, and
Vulnerabilities. Charts showing overall progress are also available.
Step 10: Repeat as needed

Each month, detections for a number of Vulnerabilities, Updates, Spyware, Security Threats, Blocked
Applications, etc. are released. Patching must continue, and the process never ends. The ability to centrally
manage this process is available, but the work never ends.
Toolbar options in the Patch and Compliance Tools

The options available in the Patch and Compliance toolbar include: Type, Filter, Download updates, Create a
task, Configure settings, Charts, Create custom definition, Import custom definitions, Export selected custom
definitions, Scan information, Computers out of compliance, Refresh, Delete selected items, Purge patch and
compliance definitions (administrator only), Disable replaced rules, and Help. Understanding the options
available helps understand how to centrally manage the patch process.
Type (Downloadable Content Types)

The downloadable content types are listed in Type in the Patch and Compliance tool.
These were discussed previously in Downloadable Content Types section above.
Select a scope
The select a scope option allows you to see a scopes autofix as well as its scan counts.

Filter
The filter option allows limiting the view for the thousands of vulnerabilities to logical groups based on
Operating Systems, and/or Severity.
This can be useful when trying to see and decide which vulnerabilities to be scanned.
To create and apply a filter, do the following:

2. Click Tools or Toolbox > Security and Compliance > Patch and compliance. (The Patch and
Compliance tool opens at the bottom of the Console.)
3. Click the down arrow to the right of Filter, and click Manage Filters. (The Manage Filters window
appears.)
4. Click [New]. (The Filter Properties window appears.)
a. Enter a name in the Filter Name field.
b. Click to select Filter operating systems (if desired) and select the desired options.
c. Click to select Filter severities (if desired) and select the desired options.
d. Click to select Scope counts (if desired) and select the scope desired.
5. Click [Close]. (The Manage Filters window reappears.)
6. Click to select the desired filter, and click [Use filter].
The filter is created, and the Patch and Compliance tool window reflects the view based upon the selected
filter.
Download updates
The download updates option launches the download updates tool.
This was covered previously in the Download definitions section.
Create a task
The create a task option brings ability to create various tasks related to Patch Management.
The options for Create a task are the abilities to create:

 Security scan – Create scheduled tasks for patch scanning on managed devices. (This is covered in more
detail in the Scan managed devices to determine existing vulnerabilities section, above.)

 Compliance scan – Create a task to run a scan for items in the Compliance group.
 Change settings – Create a task to change the Distribution and Patch (or any other Agent setting) on
managed devices.
 Reboot – Create a scheduled task to reboot managed devices.
 Repair – Create a scheduled task to remediate vulnerabilities on managed devices. This was described
earlier in the Deploy Remediations section.
 Gather historical information – Create a scheduled task to periodically gather historical information for
graphs and reporting in Patch and Compliance.
Configure settings
The configure settings option provides the access to create a setting for Patch and Compliance to utilize.
Strategically, this allows ability to have Patch Scans scan for different types, as well as have different settings
for different groups of managed devices.
The options for Configure settings are the abilities to create configuration setting for:
 Agent settings – Create or edit agent settings to be used by managed devices while scanning. This was
explained in the Distribution and Patch Agent settings above.
 Definition group settings – Create or edit settings to set scan status, group membership, and autofix
state for newly downloaded definitions by type, severity and comparison. Settings in this option are applied
the first time a definition is downloaded.
 Alert Settings – Configure which new definitions, or antivirus actions will automatically be added to the
Alert group when they are downloaded. The Alerting tool configures an alert to be sent when definitions are
added to the Alert group.
 Core settings – Set the following settings here:
o Scan results: Set whether to keep scans in the ldlogon\vulscanresults folder after processing. Also,
set whether to decompress files if necessary.
o Autofix retry count: Set whether to attempt autofix a set amount of times (1 is the default setting)
before giving up, or whether to attempt autofix indefinitely.
o Rollup core: Set whether to send scan results to a rollup core immediately, and if selected the name
of the rollup core and the URL to use to send results.
 Permissions: Set the effective permissions regarding Patch and compliance to users in the User
Management tool.
 Manage tags: Allows setting tags on definitions for counting and deployment purposes.

Display dashboard in a separate window
The display dashboard in a separate window option provides ability to pull the Patch and compliance
dashboard out as separate window.
Import definitions
The import definitions option provides the ability to import vulnerability or custom definitions.
This allows importing vulnerability or custom definitions from other Core Servers to implement on this Core
Server.
Export selected custom definitions

The export custom definitions option provides the ability to export vulnerability or custom definitions.
This option gives ability to save a vulnerability or custom definition to a share. It is then available to be
imported to other Core Servers.
Scan information
The scan information option provides access to quickly view a variety of reports regarding scan information.
In the scan information windows there is quick access to:

 Computers not recently reporting: Reports which managed devices have not reported a security and
patch scan recently. (Fields show the Device Name, OS Type, OS Name, IP address, Last Vulnerability
Scan Date, Last Spyware Scan Date, Last Security Threat Scan Date, Last LANDESK Update Scan Date,
Last Custom Definition Scan Date, Last Blocked Application Scan Date, Last Software Updates Scan Date,
Last Driver Updates Scan Date, Last Antivirus Updates Scan Date, and Last Compliance Scan Date.)
 Computers with no results: Reports which managed devices have not reported any security and patch
scan. (Fields show the Device Name, OS Type, OS Name, and IP address.)
 Computers needing patches by severity: Reports by severity (Service Pack, Critical, Important/High,
Moderate/Medium, Low, NA, Unknown) for each managed device.
o The toolbar of scan information provides options to:
 Refresh: To refresh the list of known vulnerabilities.
 Adjust thresholds: To adjust the threshold for devices not recently scanned. (7 days is the default).
 Columns: To set column selections and order of appearance.
 View as report: To view scan information as a report.
 Help: To search on-line help for Patch and Compliance.
 Type: Allows reports to be isolated by type.

Computers out of compliance
This option gives ability to view computers that have run a Compliance Scan and are vulnerable to items
placed in the Compliance Group.
Refresh
This option refreshes the view of the windows active in the Patch and Compliance tool.
Create custom definition

The create custom definition option provides the ability to search for items which would otherwise “fly under the
radar” and not be detected.
This crucially advantageous and versatile feature provides ability to search for custom definitions you define
yourself. The definitions can be defined by:
 Operating System: Mac, Linux, Unix, or Windows.
 Software Product: Including those from various vendors.
 Query: As defined by a Management Suite query.
 File: If a file exists or does not exist.
 HKLM Registry: If a registry key exists, its value, or its data.
 Custom Script: As defined by an imported or input VBScript.
The patch scanner, vulscan.exe, runs on the managed devices and reports devices vulnerable, as defined in
the definition. Actionable remediation can be acted upon by:
 Script: A VBScript.
 Patch: A downloaded patch.
 Commands: A variety of commands including:
o Click a button
o Connect to UNC share
o Copy a file
o Execute a program
o Reboot a computer
o Replace text in a file
o Run script
o Start a Windows service
o Stop a Windows service
o Unzip a file
o Write a value to the registry
The steps to accomplish this are as follows:
Additionally any vulnerability, security threat, or other Patch and Compliance type can be examined using the
Custom Definition feature. To do this, perform the following:

1. Open the Console, and open the Patch and Compliance tool.
2. Locate and select the vulnerability, security threat, or other Patch and Compliance type object, right-click
the item, and click “Clone”. (The Properties for CD-##### window appears.)
3. Find the Detection rule(s), and Edit them to find what rules and settings detect the item.
4. Search and discover the Detection Logic, Detecting the Patch, and Patch Installation and Removal
sections of the vulnerability.
You can cancel out of these windows once you have discovered all you want about the vulnerability if you do
not want to create a clone.
For more information from the Ivanti Community website on How to Create Custom Definitions in
LANDESK® Management Suite 9.0 please go to: http://community.ivanti.com/support/docs/DOC-7549
The Description tab describes the vulnerability.
See the More Information at field at the bottom of the Description tab. There is usually a link to a
manufacturer provided definition of the vulnerability.
Properties
This option provides the ability to view properties of vulnerabilities, custom definitions, and all content types in
the Patch and Compliance tool.
Selecting Properties brings up multiple tabs and grants ability to look at all aspects of each item in the Patch
and Compliance tool.
Delete selected items

This option provides the ability to delete the items accessible in the Patch and Compliance tool.
Purge patch and compliance definitions (administrator only)

This option gives Console users with the Management Suite Administrator right the ability to purge items in
the Patch and Compliance tool.
This option gives more versatility that the previous option by giving ability to purge by OS platform, language,
and/or type.
Disable replaced rules

This option enables the ability to set superseded vulnerabilities to not be searched for in a vulnerability scan.

For more information regarding this, please see the Disable replaced rules section.
Help
Provides access to the help in the Patch and Compliance tool.
The help is context sensitive and updated with latest product versions to include how to use a tool, and defines
each selection possible in configuring and utilizing the tool.
Utilizing a Rollout Project to Automate Patch

Deployment
Rollout Projects is new in Management Suite 2016. It is a tool which can automate Software Distribution as
well as Patch Management. Rollout projects are actionable objects, and as such can be:
 Owned by Users or Teams
 Grouped hierarchically in the Rollout projects tool
 Exported and synchronized to other Core Servers
Patch Management Use Case

The use case for using rollout projects for patch management is far more reaching, more advantageous, and
most impressive. With the nature of patching, and the never-ending need to download and apply patches
throughout the enterprise, you can create a rollout project to continually download patch definitions as they
become available, and have them rollout in a logical, methodical manner, automatically. You can make the
monumental, laborious, and pain-staking process, virtually hands-free! Such an ability is ground-breaking and
unprecedented!
The compelling reason to set up patching in a rollout method, is to detect those few patches (which come from
time-to-time) that break something in the enterprise, early in the process. By applying patches in a rollout
manner, (deploying to a small group of devices, then to a larger group of devices, then to all devices in the
enterprise) you should detect patches that break something early in the process, and make corrections, before
the patch is deployed throughout the enterprise. The only need for hands-on is if and when such a patch
comes down. If no such patch comes, the entire process of downloading definitions, detecting the devices that
need the patches applied, downloading the remediation files, and deploying the fixes in a rollout manner
throughout the enterprise, (with a bare-minimum impact to local and wide-area network traffic) can all be
automated.
Example patch rollout project
To create a rollout project to automate deploying LANDESK patches, set up the definition download settings to
always add LANDESK patches to the rollout project. Apply the patches to your test group, send an email that
the patches have been downloaded and applied, then wait until an administrator confirms that the patches are
working successfully. Deploy the patches to a pilot group, and then when the patches are installed on 85% of
the devices, set the patches to Autofix and tag them with an Autofix tag to make them easy to identify.
In this example, you change the definition download settings to add content automatically to a rollout project.
When you use this feature, the downloaded content is added to the project and automatically begins to move

through the project steps the next time the project processor runs. Since this feature requires no administrative
oversight after it is set up, the only intervention will be IF a patch comes down that breaks something.
This example has three steps:
 Step One
o Action: A scheduled task that applies the patch to your test group.
o Exit criteria: An 85% success rate, meaning that the patch must be installed on 85% of devices.
o Exit criteria: Administrator approval.
o Email: After the success rate has been met, you get an email saying that the content is waiting for
approval.
 Step Two
o Action: A policy-supported push task that applies the patch to your pilot group.
o Exit criteria: An 85% success rate, meaning that the patch must be installed on 85% of devices.
 Step Three
o Action: Set the patch to Autofix.
o Action: Tag the patch as Autofix.
Implementation
Configuring Rollout Projects includes creating steps to carry out the process. Rather than using if . . . then
logic, each step performs actions on all content in that step. Steps have three possible outcomes, including:
 Continue on to the next step
 Stop because the exit criteria have not been met
 Approval is required for content to continue to the next step
Project Step Properties for a Patch Management Project Rollout

Steps contain Actions, Exit criteria, Email (which is optional), and Action history.
Actions – Autofix settings

The autofix settings page lets you enable/disable the autofix setting (by scope). Option settings include no
change, global autofix enabled, or global autofix disabled.

To add a template to be selected, open the scheduled tasks tool, right-click task template and click New.
An option will be presented to select software distribution template, or patch template.
Actions – Group membership

The group membership page lets you change group membership of individual patch definitions. The group
selection in patching is used to determine which patches vulscan.exe will include to detect and remediate
patches. The options here are to either add or remove definitions to or from a group or groups.
Actions – Scan settings

The scan settings page lets you change scan status of patches (and associated remediations). The scan
status of scopes can be set to no change, scan, approved for scoped scan, unassigned, or do not scan. The
options here are to either enable scanning for the scopes or to remove scopes from scanning.
Actions – Tags
The tags page lets you specify tags to add and/or remove from definitions. Definitions can be assigned tags to
designate them for actions.
Actions – Patch task template

The patch task template page lets you select a patch management task template to create of repair a task. In
the patch management task template, you can select to use accelerated push, display in a portal, or policy
supported push.
Actions -Targets
The targets page lets you select the devices to scan patch definitions and apply remediations to. You can
select by targeted devices, targeted LDAP objects, targeted queries, targeted LDAP queries, targeted device
groups, and targeted scopes. It will even utilize targeted time zones.
Exit criteria
Specifies the exit criteria that must be met before content in this step can advance to the next step of the
workflow (or exit the workflow). The exit criteria page offers the two following options:
 Keep content together: Let’s you select whether the keep all content together before advancing to the
next step.
 Expected step duration (for charting purposes only): Designates the timeframe length the Gantt chart
will use to display the action history.
Exit criteria - Minimum duration

The minimum duration page offers the option to require a minimum duration after actions and lets you set the
minimum duration timeframe.
Exit criteria - Success rate

The success rate page offers the option to verify minimum package deployment success rate, and lets you
set what percentage of targets constitute a minimum success rate.
Exit criteria - Additional duration

The additional duration page offers the option to require an additional duration after success criteria is met,
and lets you specify the additional duration timeframe.

Exit criteria - Approval
The approval page offers the option to require approval before the content in the step can advance to the next
step of the project.
Exit criteria - Date time window

The date time window page offers the option to use a date time window to set when to exit a step. If the
success rate has not been met, this exits the step and triggers the duration has been exceeded email (if it is
configured).
Email
The Email section is dependent on the email defaults settings of step duration exceeded, exit criteria met,
approval, and recipients all configured on the Rollout project properties page.
Email - Duration exceeded

The duration exceeded page lets you select whether to send email when duration is exceeded, and lets you
set to use project defaults (don’t send email), don’t send email, or send email.
Email – Exit criteria met

The exit criteria met page lets you select whether to send email when exit criteria is met, and lets you set to
use project defaults (don’t send email), don’t send email, or send email.
Email – Approval
The approval page lets you select whether to send email when approval is required, and lets you set to use
project defaults (don’t send email), don’t send email, or send email. It also allows you to only send on email
during a configurable timeframe to avoid an email blast.
Action history
An action history shows detail of successes, failures, and warnings. A Gantt chart of items in a project can be
accessed by double-clicking an item in a step of rollout projects.
Rollout Project Properties

The rollout project properties window begins the creation of the rollout project, and configures the email
defaults required if steps are going to use email actions.
General
On the General page you select the following:
Project Type: Select either patch management, or software distribution. You must select the project type and
save the project before you can add steps to it.

State: Select either pause (exclude from processing), or play (include in processing). The state must be set to
pause in order to create, add, or edit, steps to the rollout project. When a project is first created, it defaults to a
paused state. If the project is set to pause, the project processor ignores the project and content stays in the
step it is assigned to. When the project is set to play, the project processor evaluates the content in each step
and determines which content needs to move to the next step.
User scope when creating tasks: When you create tasks associated with the project, the tasks are limited to
the scope set for the project. Rollout projects use the same scopes that are used in the rest of Management
Suite.
Email defaults
On the email defaults page you set project default options for sending email notifications.
Email defaults – Step duration exceeded

These settings control the project defaults for whether to send an email if content remains in any step longer
than the duration exceeded setting. Options include:
 Select whether to send email when duration is exceeded: Select either don’t send email, or send email.
 Duration exceeded threshold: Set the duration timeframe.
 Don’t send more than one email per: Set the timeframe to only send one email to avoid an email blast.
These settings can be overridden on a per-step basis.
Email defaults – Exit criteria met

Select whether to send email when exit criteria is met. Select either don’t send email, or send email. This
setting can be overridden on a per-step basis.
Email defaults – Approval

Sets the following settings:
 Select whether to send email when approval is required: Select either don’t send email, or send email.
 Don’t send more than one email per: Set the timeframe to only send one email to avoid an email blast.
These settings can be overridden on a per-step basis.
Action history
The action history page allows you to view what actions have been performed by the rollout project, and what
content was involved. Each time content enters a step, has actions applied, or is evaluated against exit criteria,
that information is tracked in the action history.

Use the action history page to search actions, or sort actions based on date, success or failure, or if they were
performed for the entire project, a step, or content.
Rollout Projects Toolbar
New project or project step: Click to create a new project, or add steps to an existing project.
Properties: Click to access the Rollout project properties window.
Delete selected object: Click to delete a rollout project step, rollout project, or rollout group.
Pause (exclude from processing): Click to pause a rollout project. If the project is set to pause, the
project processor ignores the project and content stays in the step it is assigned to.
Play (include in processing): Click to play a rollout project. When the project is set to play, the project
processor evaluates the content in each step and determines which content needs to move to the next
step.
Display dashboard in a separate window: Click to have the dashboard pop-out in a separate window.
Create a task: Click to create a task to schedule project processing. This will create scheduled tasks to
carry out the project rollout.
Configure settings: Click to configure email send options. This presents the following options:
 Sender’s address: Sets the address that appears in the from field in the email. Email recipients can
know to whom they should turn, should they have questions about the email.
 SMTP server: Sets the address of the SMTP server which will send the email(s).
 Port: Sets the port the SMTP server will use to send the email(s).
 User name: A username to access the SMTP server.
 Password: A password to access the SMTP server.
 Addresses: Sets a global email recipients list that will combine with the list configured on the email
defaults – recipients page of each rollout project.
Help: Click to access the Management Suite Help.

There is a rollout projects for patch management exercise.
Check for Understanding of Patch Management
1. What types of contents can be downloaded from subscription servers and implemented in Patch
Management?
2. What are the steps to Implement Patch Management?
3. What does Rollout Projects do to assist in Patch Management?

Ivanti Cloud Services Appliance
Module Objectives
In this overview section you will learn:
 Cite business solutions the Ivanti Cloud Services Appliance provides

 Describe the Cloud Services Appliance
 List features of the Cloud Services Appliance
 Describe placement of the Cloud Services Appliance
 Configure the Cloud Services Appliance
 Check for Understanding of the Cloud Services Appliance

Solutions provided by the Ivanti Cloud Services
Appliance (Powered by Landesk)
The Ivanti Cloud Services Appliance (Powered by Landesk) is a tool that allows you to manage devices, using
Ivanti Management Suite (Powered by Landesk), through the Internet, without using a Virtual Private Network
(VPN). Managed devices can update inventory, be remotely controlled, and receive software, patches, or even
an OS image, via the Cloud Services Appliance.
Imagine managing a device connected to the internet, anywhere in the world, from your Management Suite
Console! Such is not only a theoretical possibility, but it actually occurs, on a daily basis, throughout the world,
with the Cloud Services Appliance. Any task that Management Suite can do to managed device, which is
initiated by the device, can be done through the Cloud Services Appliance. Examples of managing a Client
through a Cloud Services Appliance may include:
 Inventory (LDISCN32.EXE started from the managed device’s Local Scheduler).

 Patch Scanning (VULSCAN.EXE started from the managed device’s Local Scheduler).
 Software Distribution (scheduled as a policy from the Core Server, started from the managed device’s
Local Scheduler launching PolicySync.exe)
 Operating System Deployment (scheduled as a policy from the Core Server, started from the managed
device’s Local Scheduler launching PolicySync.exe)
 Remote Control (ISSUSER.EXE set to Gateway mode on the managed device) for more information
see the Ivanti Community Website article at: http://community.ivanti.com/support/docs/DOC-23981.
 Antivirus Pattern File Updates from Core Server (launched from the managed device’s Local
Scheduler).
In network communications within a corporate firewall, managed devices with the Management Suite Agent,
communicate via routers, switches and hubs, through the corporate network, to communicate with the
Management Suite Core Server.
In network communications outside the corporate firewall, through the Internet, intricate and expensive
implementations including routers, switches, hubs, virtual private networks (VPNs), and firewalls, are
assembled, connected, configured, and used.

The Cloud Services Appliance makes Client to Core Server communication (and management) possible, and
secure, without expensive VPNs. All communication from the Client to the Cloud Services Appliance and from
the Cloud Services Appliance to the Core Server is done via a Secure Socket Layer (SSL) connection on port
443. (Port 443 is generally open in even the most secure network environments.)
What is the Cloud Services Appliance

The physical Cloud Services Appliance is a 1u thick Server that can be mounted in a universal server rack. It
has two hard drives (mirrored, for redundancy), a CPU, Memory, a power supply, and two Gigabit Ethernet
connections (for redundancy or throughput), and other robust hardware features built to last for many years of
use and service.
A virtual version is also available for download and implementation on any local machine in your demilitarized
zone (DMZ).
Whether you use a physical or virtual version, the Cloud Services Appliance acts as a gateway between
managed devices throughout the world, and the Core Server.
The Cloud Services Appliance, by default, is set to handle 4000 simultaneous connections, each device
requiring two (2) separate connections. One connection is required to the Cloud Services Appliance from the
Client, and one connection to the Core Server from the Cloud Services Appliance, for a total of 2,000
simultaneous Client connections. If there is a need for more connections, multiple Cloud Services Appliances
can be implemented.

Cloud Services Appliance Security
Due to its facilitation of powerful and versatile management to key IT assets, significant security precautions
are built in to the Cloud Services Appliance, including:
 The Cloud Services Appliance operating system is a custom 64-bit Linux architecture running on
CentOS6.
 All communication between the Client and Core Server utilizes SSL communication on port 443
(usually open by default on the most secure networks).
 The usual Web interface for Linux (Apache) has been removed and replaced by a proprietary, secure,
Ivanti Web interface.
 Certificate services are installed and utilized on each Cloud Services Appliance.
 SUMO (checksum scanner) protects all operating system and vital files by running scans on key files
every few minutes, to assure the files have not been changed or compromised - by cyber-attack or
virus infection - in any way. In the event a key file was compromised, an e-mail would immediately be
sent to an administrator for immediate action to be taken.
 Built-in firewall protection and port limitation is utilized on each Cloud Services Appliance.
 Robust logging can be implemented further protecting the Cloud Services Appliance by providing
valuable information in the event of a successful cyber-attack or virus infection.
 “Root”, the key Linux account, has been removed further protecting the Cloud Services Appliance from
cyber-attacks.
 Passwords for all accounts on the Cloud Services Appliance require strong passwords
o 8 characters at a minimum

o Requires alpha, numeric, and special characters in each password
 Backups are run automatically at regular intervals, and additional backups (and restores) can be done
quickly and easily as desired.
 Meets Federal Information Processing Standard (FIPS) 140-2 requirements.
Notable Features of the Cloud Services Appliance

HTML Remote Control
The Cloud Services Appliance can use HTML Remote Control. This creates the ability to use an Internet
Browser to connect a remote control session, without a console having to be installed.
Virtual Cloud Services Appliance

A Cloud Services Appliance can be a virtual device making it more portable and usable.

The Cloud Services Appliance meets Federal Information Process Standard (FIPS) 140-2 requirements.

or later.
 The broker daemon on the Cloud Services Appliance.
Placement of the Cloud Services Appliance

The Cloud Services Appliance must be accessible from the Internet. The Client devices attach to the Internet,
contact the Cloud Services Appliance, which then routes them to the Core Server. To do this, place the Cloud
Services Appliance between the Intranet and the World Wide Web. You can setup IP Address Port Forwarding

to reach the Cloud Services Appliance, or the Cloud Services Appliance an also be setup in a demilitarized
zone (DMZ) environment as well.

Cloud Services Appliance – Port Forwarding Configuration
Cloud Services Appliance Placement in the Demilitarized Zone (DMZ)
Seeing that the Cloud Services Appliance is in a more vulnerable place for cyber-attack, the Cloud Services
Appliance Security precautions are in place.
Configuring the Cloud Services Appliance

To configure the Cloud Services Appliance a direct connection can be made from a Console to the Cloud
Services Appliance itself, or through a Secure Shell (SSH) connection. Alternatively, a web browser can
connect to the Cloud Services Appliance via a web browser. Either requires username and password
authentication for security reasons.
To support connectivity from a web browser the Cloud Services Appliance is configured with two IP Addresses.
One comes from the Intranet side, while the other comes from the Internet side. Either can be used to connect
with rights to configure the Cloud Services Appliance.
To connect to the Cloud Services Appliance via SSH, see the Ivanti Community Article at
To connect to the cloud device via browser simply go to https://ip_address or DNS_Name/gsb.
Steps to configure the Cloud Services Appliance

To configure the Cloud Services Appliance:
1. Install the Cloud Services Appliance hardware in the server room in the server rack. It will need to be
able to access the two (2) Ethernet cables which will provide connectivity to:
a. The Intranet – where it can contact the physical segment where the Core Server resides.

b. The Internet – World Wide Web, including the Public IP Address and Public Name where the
URL will route traffic from the Internet to the Cloud Services Appliance.
2. Connect all cables to the ports on the back of the Cloud Services Appliance. For instructions on how to
do this, please see the Ivanti Community article at: http://community.ivanti.com/support/docs/DOC-
23246.
3. Connect to the Cloud Services Appliance. For instructions on how to connect to and configure the
Cloud Services Appliance please see the Ivanti Community article at:
http://community.landesk.com/support/docs/DOC-26157.
4. Configure the Cloud Services Appliance. For instructions on how to configure the Cloud Services
Appliance please download the Best Known Method available from the Ivanti Community article located
at: http://community.landesk.com/support/docs/DOC-3257.
5. Configure the Core Server to utilize the Cloud Services Appliance.
6. Post the Public Certificate from the Core Server to the Cloud Services Appliance.
There is a complete set of documentation concerning the Cloud Services Appliance on the Cloud Services
Appliance landing page on the Ivanti Community website at: http://community.landesk.com/support/docs/DOC-
10162.

you want to manage.
mode?)
LANDESK Software Services window will appear stating: “The LANDESK Management Gateway Service
must be restarted before your changes will take effect. Do you wish to restart it now?)
29. If this Configure LANDESK Software Services window appears, Click [Yes].
30. A Configure LANDESK Software Services window appears stating: “You must restart the services that use
the database before your changes will take effect.” Click [OK].
32. Click [OK]. (The Configure LANDESK Software Services window closes.)


Check for Understanding of the Cloud Services
Appliance
1. What port does the Cloud Services Appliance use to communicate with the Core Server and Managed
Devices?
2. What security features does the Cloud Services Appliance have?
3. How can you connect with the Cloud Services Appliance from an outside device to configure or change
configuration on the Cloud Services Applance?
4. What is FIPS 140-2 and how do you enable it on the Cloud Services Appliance?
5. What are strengths and weaknesses of having a physical vs a virtual Cloud Services Appliance?

Ilt LDSSM 1601.1 CG

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ilt LDSSM 1601.1 CG

Încărcat de

Drepturi de autor:

Formate disponibile

Course Guide

Systems and Security

© 2017, Ivanti, . All rights reserved. IVI-0001 1/17

Systems and Security Administration Boot Camp 2016.3 2

Systems and Security Administration Boot Camp 2016.3 3

Systems and Security Administration Boot Camp 2016.3 4

Systems and Security Administration Boot Camp 2016.3 5

Systems and Security Administration Boot Camp 2016.3 6

Systems and Security Administration Boot Camp 2016.3 7

Systems and Security Administration Boot Camp 2016.3 8

Systems and Security Administration Boot Camp 2016.3 9

Systems and Security Administration Boot Camp 2016.3 10

Systems and Security Administration Boot Camp 2016.3 11

Systems and Security Administration Boot Camp 2016.3 12

Systems and Security Administration Boot Camp 2016.3 13

Systems and Security Administration Boot Camp 2016.3 14

Systems and Security Administration Boot Camp 2016.3 15

Systems and Security Administration Boot Camp 2016.3 16

Systems and Security Administration Boot Camp 2016.3 17

Management Suite 2016

What Management Suite 2016 enables you to do

Systems and Security Administration Boot Camp 2016.3 18

Where to go for more information

Systems and Security Administration Boot Camp 2016.3 19

Systems and Security Administration Boot Camp 2016.3 20

 Prepare a design for the Management Suite Domain

Systems and Security Administration Boot Camp 2016.3 21

Planning the Organization Model

Systems and Security Administration Boot Camp 2016.3 22

Selecting components to implement

Understand compatibility with previous versions of Management Suite

Systems and Security Administration Boot Camp 2016.3 23

Systems and Security Administration Boot Camp 2016.3 24

Install / Upgrade to Management Suite 2016

Install/Upgrade Method Core Server Database

Systems and Security Administration Boot Camp 2016.3 25

Other installation documents on the Ivanti Community Website

Management Suite 2016.3 Installation Steps

Systems and Security Administration Boot Camp 2016.3 26

Systems and Security Administration Boot Camp 2016.3 27

Click the [Install] button.

Systems and Security Administration Boot Camp 2016.3 28

Click the [Continue] button.

Systems and Security Administration Boot Camp 2016.3 29

Select the desired installation language, and click [Continue].

Systems and Security Administration Boot Camp 2016.3 30

Systems and Security Administration Boot Camp 2016.3 31

Select the Core Server radio button, and click [Continue].

Systems and Security Administration Boot Camp 2016.3 32

Systems and Security Administration Boot Camp 2016.3 33

Systems and Security Administration Boot Camp 2016.3 34

Systems and Security Administration Boot Camp 2016.3 35

Select the desired location and click [Continue].

Systems and Security Administration Boot Camp 2016.3 36

Systems and Security Administration Boot Camp 2016.3 37

Systems and Security Administration Boot Camp 2016.3 38

Systems and Security Administration Boot Camp 2016.3 39

Systems and Security Administration Boot Camp 2016.3 40

2. Download the installation file from

Systems and Security Administration Boot Camp 2016.3 41

Click the [Continue] button.

Systems and Security Administration Boot Camp 2016.3 42

Systems and Security Administration Boot Camp 2016.3 43