Content Items - Metadata

Content Items are stored in DeployR in seperate places. The Metadata is stored in the database, while the file content (WIM files) are stored on the DeployR Content Folder. Lets look more closely at the Metadata side.

Get-DeployRContentItem

Metadata Properties

• id: DeployR Unique ID (GUID) created at the time of the item's creation.

  • Built in Items typically start their pre-assigned ids with 00000000

• name: Friendly name of the item that is display in the console

• description: optional field to include additional information

• contentItemType: a property to let DeployR know how to handle the content

  • URL: a link to a single file that is stored on a web server

  • File: uploading of a single file, typically used with Operating Systems (.wim file)

  • Folder: uploading an entire folder of content, this is probably the most common use case

• contentItemPurpose: a property to let DeployR know how to categorize the content, filtering it in other areas of DeployR

• versions: this is a JSON blob that contains additional details about the individual version, of which there can be many per item. This will look different depending on the purpose of the item. See the detailed areas to dig in more.

• versionCount: the count of versions associated with an item

• createdDate: the date the item was orginally created in DeployR

• lastModifiedDate: the date the item was last modified by a user or process

• readOnly: [True / False] lets you know if you can modify the item. Built in items are set to True.

Versions Deeper Drive. This metadata is consistent amoung different content item purposes, however not all items are used, it depends on the purpose.

• id: a unique GUID created for each version

• contentItemID: the GUID id of the parent content item.

• versionNo: the version count in the content item

• status: the current status of that version (In Development, Active, Deprecated)

• description: an optional property that you can provide additional information

• relativePath: where the content WIM file resides in your DeployR Content folder

• contentSize: size of the compressed WIM file on your server

• externalURL: used when you choose "URL" from the type

• createdDate: date the version was created

• lastModifiedDate: date of the last modificiation to the version

• installationCommandLine: command used to trigger the installation of the app content

• installationWorkingDirectory: typically left blank, but if you need to change the path, you can

• installationSuccessCode: 0 (success) and 3010 (reboot required) are the standard ones you can add, but based on your application, you might have others.

• installationDependancies: currently not used, place holder for future enhancements

• driverManufacturer: used in driver packs to specify the manufacturer (MakeAlias)

  • used in the automatching step of "Inject Drivers"

• driverModel: used in driver packs to specify the model (ModelAlias)

  • used in the automatching step of "Inject Drivers"

Applications

Standard metadata of an Application Content Item, one that has 2 versions embedded.

versions metadata:

Here you can see there are two versions inside the single content item. Only 1 verison is required per content item, but this example, a second was added when an updated release of the app came out. This is one potential way to manage versioning of applications in DeployR.

Operating Systems

Operating System Content Items are for you to keep your operating systems. :-) I'll only be covering Windows here, but in the future, I'll circle back for Linux.

Below is the output of an Operating System Content Item. It has two versions, one with the Windows 11 24H2 March WIM (26100.3476), and one with the July WIM (26100.4652)

Driver Packs

Driver packs will be your extracted driver pack uploaded into a Single WIM. In this example, in the versions area, you'll see the driverManufacturer and driverModel are both set, this is to allow the auto matching future to work. The task sequence will read in all of the driver packs, then match on those two properties.

Other

This is like a bucket for you to keep other things in. Common uses:

• Scripts

• Certificates

• Task Sequence Support Tools

• other things that don't fit into "Application, Operating System, or Driver Pack" items.

Here are two examples, one of a Folder item which contains serveral files that are used to inject into WinPE named "WinPE-Extras", and one that is a single file containing a boot image used some random testing I was doing. Here is another example below of a content item I have placed many powershell scripts that then get leveraged in custom step defintions. While all of the metadata options are available, many are not used in "other" content items: