Improvements for the Beta

Developer
Jun 28, 2011 at 12:12 PM

This post will be iterative ;) I'll try to give as much feedback about the usage as I try to implement my SCCM Policies using the Beta

CreatePackage

I really miss the option to supply the CreatePackage Funktion with all the fields that I can modify using ModifyPackage. Because you can only modify one Packageproperty per Opalis object the policies might get huge.

ModifyPackage

See comment about CreatePackage. My proposal: use ModifyPackage to modify ALL Objects and where the field has been altered by a value, replace it. If it has no value, keep the value of the SCCM Package. (a rather complex logic, but would greatly improve the handling of the packages and the ModifyPackage Object. Should also improve the scaling ;) )

 

Keep an eye out for more feedback

Coordinator
Jun 28, 2011 at 1:39 PM

Hey,

First off there is a bug with the ‘collection’ class that will be fixed soon ™ -- hopefully end of day – so be aware of that as you test. As for your suggestions they are appreciated! The reason I designed the ‘Modify Package’ and ‘Create Package’ objects the way I did was to allow for people who have extended their MOF definition of ‘packages’ to be able to use these objects against their custom attributes. What you are suggesting is actually not the largest code change in the world and I am open to making it. I however am not an SCCM expert (Opalis and Operations Manager are more my purview) so I do not know if people ever do extend the MOF definition for things like packages or if they only use the defaults. There is a good argument for only exposing the default properties though, those are the only ones I publish as package data in my package definition class. Can you think about this a bit and let me know what you believe would be most appropriate?

-Ryan

From: cvoigt [email removed]
Sent: Tuesday, June 28, 2011 7:13 AM
To: Ryan Andorfer
Subject: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

This post will be iterative ;) I'll try to give as much feedback about the usage as I try to implement my SCCM Policies using the Beta

CreatePackage

I really miss the option to supply the CreatePackage Funktion with all the fields that I can modify using ModifyPackage. Because you can only modify one Packageproperty per Opalis object the policies might get huge.

ModifyPackage

See comment about CreatePackage. My proposal: use ModifyPackage to modify ALL Objects and where the field has been altered by a value, replace it. If it has no value, keep the value of the SCCM Package. (a rather complex logic, but would greatly improve the handling of the packages and the ModifyPackage Object. Should also improve the scaling ;) )

Keep an eye out for more feedback

Coordinator
Jun 28, 2011 at 1:46 PM

Also, keep in mind that you could create a ‘package customization’ workflow that sets all the properties you want in one policy (Multiple Objects) then call and pass the values for those properties from another policy using trigger policy (kind of making the ‘custom’ set package object you want)

From: cvoigt [email removed]
Sent: Tuesday, June 28, 2011 7:13 AM
To: Ryan Andorfer
Subject: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

This post will be iterative ;) I'll try to give as much feedback about the usage as I try to implement my SCCM Policies using the Beta

CreatePackage

I really miss the option to supply the CreatePackage Funktion with all the fields that I can modify using ModifyPackage. Because you can only modify one Packageproperty per Opalis object the policies might get huge.

ModifyPackage

See comment about CreatePackage. My proposal: use ModifyPackage to modify ALL Objects and where the field has been altered by a value, replace it. If it has no value, keep the value of the SCCM Package. (a rather complex logic, but would greatly improve the handling of the packages and the ModifyPackage Object. Should also improve the scaling ;) )

Keep an eye out for more feedback

Developer
Jun 28, 2011 at 6:00 PM

Hey Ryan,

in the last 6 years that I'm working with SMS/SCCM I haven't met or read about anyone who actually customized their package attributes in SCCM. imho it's pretty safe to say that exposing the default attributes is more than enough for the audience your IP is targeted at. However, I like the idea of modifying only a single, targeted property without touching the rest of them. I'm currently using ModifyPackage like you described it (that is: create package with name only and pass packageid and other required package attributes [name, version, manufacturer] to a "modifypackage" policy) and it works great too. It's just not very admin-friendly.. :)

What collection class bug are you talking about?

Coordinator
Jun 28, 2011 at 7:38 PM

If your collection has a refresh schedule set up the object may ‘fail’ and return no data. This was just because of poor error handling on the class definition on my side. It has been fixed in the latest .DLL file on codeplex.

From: cvoigt [email removed]
Sent: Tuesday, June 28, 2011 1:01 PM
To: Ryan Andorfer
Subject: Re: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

Hey Ryan,

in the last 6 years that I'm working with SMS/SCCM I haven't met or read about anyone who actually customized their package attributes in SCCM. imho it's pretty safe to say that exposing the default attributes is more than enough for the audience your IP is targeted at. However, I like the idea of modifying only a single, targeted property without touching the rest of them. I'm currently using ModifyPackage like you described it (that is: create package with name only and pass packageid and other required package attributes [name, version, manufacturer] to a "modifypackage" policy) and it works great too. It's just not very admin-friendly.. :)

What collection class bug are you talking about?

Developer
Jun 29, 2011 at 2:40 PM

CreateAdvertisement

Could you include IncludeSubcollection as an optional or better required field? It's set to true by default which can pose a problem when you don't remember to change it "manually" using the ModifyAdvertisement object

 

One thing I was looking for but have not found yet is the option to move items between SCCM Console Folders. I suppose with the announced release of the IP tomorrow, it's far too late for that - but maybe you could keep it in mind for a later release :)

Coordinator
Jun 29, 2011 at 2:42 PM

Hey,

Thanks for the idea on the create Advertisement object, I will definitely put that in. As for moving items between different SCCM folders I am going to release that ‘sort’ of functionality in a different IP. That functionality is actually exposed in a differently SCCM Library that this IP doesn’t use so I will be wrapping it up separately (We internally have a need for this as well so it will be coming out soon).

From: cvoigt [email removed]
Sent: Wednesday, June 29, 2011 9:40 AM
To: Ryan Andorfer
Subject: Re: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

CreateAdvertisement

Could you include IncludeSubcollection as an optional or better required field? It's set to true by default which can pose a problem when you don't remember to change it "manually" using the ModifyAdvertisement object

One thing I was looking for but have not found yet is the option to move items between SCCM Console Folders. I suppose with the announced release of the IP tomorrow, it's far too late for that - but maybe you could keep it in mind for a later release :)

Developer
Jun 29, 2011 at 2:58 PM

Great :)

btw, did you find somebody taking care of the icons? If not, I might be able to wrap some quick ones up using the icons from http://technet.microsoft.com/en-us/library/bb680602.aspx. Is 32x32px and 16x16 sufficient?

Coordinator
Jun 29, 2011 at 3:24 PM

Hey If you have time to wrap the icons up it would be more than appreciated J. Charles Joy has a blog post about how to do this.

Ryan Andorfer - MMS 2011 Speaker – Automation Engineer

Cell: (763) 445-9680 Ryan.Andorfer@genmills.com
Description: Description: Microsoft Management Summit 201l

From: cvoigt [email removed]
Sent: Wednesday, June 29, 2011 9:58 AM
To: Ryan Andorfer
Subject: Re: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

Great :)

btw, did you find somebody taking care of the icons? If not, I might be able to wrap some quick ones up using the icons from http://technet.microsoft.com/en-us/library/bb680602.aspx. Is 32x32px and 16x16 sufficient?

Developer
Jun 30, 2011 at 12:20 PM

CreateCollection

Is there space enough for one improvement? ;) R3 introduced dynamic resource updating on collections. This is easily available within the Console but not documented on technet yet. However, you can set the RefreshType of the Collection to '6' (int)
You can use ModifyCollection for this, but it's again not very accessible and doesn't scale well.

Coordinator
Jun 30, 2011 at 2:28 PM

This seems like a pretty reasonable change to make, I will try to get it in

Ryan Andorfer - MMS 2011 Speaker – Automation Engineer

Cell: (763) 445-9680 Ryan.Andorfer@genmills.com
Description: Description: Microsoft Management Summit 201l

From: cvoigt [email removed]
Sent: Thursday, June 30, 2011 7:21 AM
To: Ryan Andorfer
Subject: Re: Improvements for the Beta [OpalisSCCMExtension:263078]

From: cvoigt

CreateCollection

Is there space enough for one improvement? ;) R3 introduced dynamic resource updating on collections. This is easily available within the Console but not documented on technet yet. However, you can set the RefreshType of the Collection to '6' (int)
You can use
ModifyCollection for this, but it's again not very accessible and doesn't scale well.

Coordinator
Jun 30, 2011 at 7:14 PM

To address most of your concerns above I am going to be modifying all of the 'modify' objects so that you can modify all of the object propertiest with the in one object.  I am not going to update the create objects (with the exception of adding the 'include sub collections' field to the create advertisement object).  Most policies will then have a create followed directly by one modify object.