cogumel0

Maybe it is me, I'm due to have my glasses changed soon you see, but I can't find anything about collections there, instead when I look at it my eyes read direct group membership. There's this thing in AD called a group. You make other objects members of groups in a way that... ...well... groups them together. So if you decide to make say ComputerA a member of Group1, you say that ComputerA is a member of Group1 through direct group membership. If, however, you make ComputerA a member of Group1 and Group1 a member of Group2, then ComputerA is also a member of Group2, only through nested group membership. Again: Daniel and Niall's solution do not work on nested groups. Neither does the one presented by me, but that can be easily changed by using the script from Richard Muller or a similar one. Just so there's no confusion going forward: neither Daniel & Niall's solution nor my solution do anything at all with collections.

Why over complicate this so much? Daniel Oxley's original post had 4 actions per application to install. Niall's still has 3 actions per application to install. Multiply that by a mere 10 applications and you've got 30 actions (+ a group per set of 3 actions making it a total of 40 steps in TS). I just do the following instead: created a 30 line script which gets the list of groups a computer is a member of. For each group the computer is a member of, it creates a TS variable where the name of the variable is the CN of the group and the value is set to True. That way, you call the script to load the groups once and then on your conditions instead of using INSTALLAPP = True you use Firefox Users = True This example works only on direct membership groups, but it can be easily modified to accommodate nested grouping by using the example here from Richard Mueller: http://www.rlmueller.net/Programs/IsMember8.txt. Should also be noted that the solution presented by both Daniel and Niall also only work in direct group membership. On top of that, the solution from Daniel works out whether a computer is a member of the group by cycling through every single member until it either finds the computer or runs out of members to check against, when there's already a IsMember() method that returns True or False and can be called as: Set objGroup = GetObject("LDAP://" & strGroupDN) If objGroup.IsMember(strComputer) Then ... Anyway, here's my alternative: <job id="ZTIBde"> <script language="VBScript" src="ZTIUtility.vbs"/> <script language="VBScript"> iRetVal = ZTIProcess ProcessResults iRetVal Function ZTIProcess() ZTIProcess = Success On Error Resume Next oLogging.CreateEntry "Retrieving direct groups membership.", LogTypeInfo Set objSysInfo = CreateObject("ADSystemInfo") Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName) If IsArray(objComputer.MemberOf) Then For Each strGroup In objComputer.MemberOf oEnvironment.Item(GetObject("LDAP://" & strGroup).CN) = True Next Else If Len(objComputer.MemberOf) > 0 Then oEnvironment.Item(GetObject("LDAP://" & objComputer.MemberOf).CN) = True End If End If ZTIProcess = err.Number End Function </script> </job> It doesn't work in WinPE as is, but why would you want it to anyway? You can't install applications whilst in WinPE (though this can be easily modified to work in WinPE too for the skeptic ones).

Thank you for the script, but that achieves the opposite of what I am trying to do. I want a new object to be created and the old one to be made obsolete, not to merge them.

How often does this happen in a day? There's an issue where some components might not start up after a database backup. One of the symptoms is collections not updating. Microsoft has a KB for this. Though to be fair if this was the issue you'd very likely notice it on other things as well (computers not able to communicate with SCCM until a restart, etc).

We have an SCCM 2007 infrastructure configured to automatically deal with conflicting objects by creating a new object. We have some TSs only advertised to PXE and some that are user initiated using UDI/ZTI from Windows. The ones that are advertised to PXE will create a new object when complete, making the old object obsolete (as expected). However, if the task sequence is initiated from Windows the objects will be merged at the end of the TS. Before booting to WinPe (but after my first Gather) I'm setting DeploymentType to "NEWCOMPUTER" but it's still merging the objects instead of creating a new one and making the old one obsolete. I'd like the object to be made obsolete and a new one created, what am I doing wrong? cogu