1 2 Previous Next 14 Replies Latest reply on May 22, 2009 3:59 PM by SafeBoot

    Multiple Install Sets vs. One Install Set

      We have four machine groups that we will be segregating machines into. These are separated into Vista and XP, and SSO and non-SSO.

      Is it recommended that a separate install set be created for each one? Or should one install set be created and then the settings inherited from the group settings?

      Obviously, having one install set would be easiest from a deployment standpoint.

      Thanks for your input.
        • 1. RE: Multiple Install Sets vs. One Install Set
          the install set is linked to the group the machine will end up in - there's no settings in the installer itself.

          so, if you indeed want these machines to all end up in different groups on install, you need 4 sets - if you want them to all end up in one group, then you're going to move them manually, you could use one install set.

          XP/Vista makes no difference though - everything is the same.
          • 2. RE: Multiple Install Sets vs. One Install Set
            woodsjw


            Related question.....

            Even though the default group is not a control group, the newly installed machines will pick up the group settings not the settings from when the install package was created?
            • 3. RE: Multiple Install Sets vs. One Install Set
              unless you use an offline install set, there's actually no settings in it at all apart from the id of the group it was created from..

              remember, the machine won't activate until it's called home and got the latest policy from the group itself.

              S.
              • 4. RE: Multiple Install Sets vs. One Install Set
                So if they are getting their settings from the group that they are placed in, I should be able to deploy only one install set (that is, one executable--EEPC.EXE), but then put the machine in the correct group to get its corresponding settings? (So, as it is now, I run the executable, then put the machine in the correct group via an API call, and then reboot the machine. Upon reboot, it will not add the machine since it already exists.) Mostly correct?

                As far as XP vs. Vista, the options for enabling Vista SSO appear to break some of the functionality in XP. One example is "Require Endpoint Encryption Logon." This option must be checked for Vista SSO, but if it is turned on for XP, XP does not appear to pick up password changes during a lock/unlock or logon/logoff sequence--it only appears to get this when rebooting and the SSO (Windows) password fails. I think it would be easier in our case to just create groups with the appropriate settings and not have to deal with those pesky users and their questions. wink
                • 5. RE: Multiple Install Sets vs. One Install Set
                  sounds like you're doing some of what Autodomain does.

                  sure you could do things like that - most people would let the machine create itself, but if you want to pre-populate then fine. Just make sure you use a persistent connection if you're running multiple api calls, and don't use a batch file.
                  • 6. RE: Multiple Install Sets vs. One Install Set
                    I have been testing it in a batch environment, but I need to see how our client implementation folks want to set it up.

                    What are the concerns with running it in a batch?

                    (BTW, thanks for your assistance with this.)
                    • 7. RE: Multiple Install Sets vs. One Install Set
                      you can't do persistent connections in a batch file, so you'll put a tremendous load on the server. You should write using the com object in VBS if possible at least.

                      but, if the script is really really simple it might be good enough if your server is able to keep up with the load.
                      • 8. RE: Multiple Install Sets vs. One Install Set
                        It does not look like we have the expertise here to get those APIs done utilizing COM objects. We are thinking about doing the following for each install:

                        1. See if current machine exists in SB (in cases of re-cores) (1 command)
                        2. If it does, rename it and move it into a "ReImaged Machines" group (2 commands, potentially)
                        3. Create "new" machine (1 command)
                        4. Create user(s) in Safeboot (can be up to 12) (1-12 commands) (usually only 1 user)
                        5. Assign user(s) to machine (1-12 commands) (usually only 1 user)
                        6. Create AD bindings for each user (1-12 commands) (usually only 1 user)

                        Anticipate ~6000 machines and ~12000 users. I would assume that most of the load we would see will be during deployment, obviously. Also, we are running the server on a VM.

                        (And I did notice that the Autodomain creates multiple service accounts--what exactly is the purpose of that? I would assume that one ID could be used, but does it do some sort of lockout on the account while it is being used?)

                        Is the load that is put on the server related to the multiple authentications that are being performed? Should we pursue getting someone to code it utilizing the COM objects? (In other words, is the load *really* that bad? What happens when the server gets overloaded? Do commands start timing out? Does the COM objects route provide for better error handling as well?)

                        Is this something that Professional Services can assist with?
                        • 9. RE: Multiple Install Sets vs. One Install Set
                          lots of questions.. and a comment, your VM server is going to be the bottleneck unless it's connected to a solid Tier1 SAN pipe or DAS. Normal VM/SAN's are REALLY slow for disk access so be prepared to move to physical/DAS if performance becomes a problem. We can't make VM faster, only you can by giving it a proper pipe to the data. It's rare to see people get anywhere near to the performance of Physical/DAS with VM, It's typically 4x slower.

                          If you implement a script and deploy it out, and it drags your server down, McAfee support is just going to tell you to migrate to a faster back end so you might want to consider "plan B" now.

                          anyway...

                          (And I did notice that the Autodomain creates multiple service accounts--what exactly is the purpose of that? I would assume that one ID could be used, but does it do some sort of lockout on the account while it is being used?)

                          >it's to spread the load across the db. logging on is one of the most expensive transactions, so having lots of accounts allows lots of parallel logons to occur, otherwise we get lockouts and performance drops. If you are not running many copies of the script at once, it does not matter. Worst case is 1 account per 10 concurrent connections, but you don't ever need more than 100 or so.

                          Is the load that is put on the server related to the multiple authentications that are being performed?

                          >yup.

                          Should we pursue getting someone to code it utilizing the COM objects? (In other words, is the load *really* that bad? What happens when the server gets overloaded? Do commands start timing out?

                          >yup. You can access COM through VBS as Autodomain does, so it's not that hard..

                          Does the COM objects route provide for better error handling as well?)

                          >not really COM itself, but the fact you access COM through VBScript/Jscript/.net etc means absolutly you have more control over whats going on as they are much richer languages.


                          Is this something that Professional Services can assist with?

                          >sure, but what are you trying to do that autodomain does not already do for you?
                          1 2 Previous Next