1 2 3 Previous Next 22 Replies Latest reply on Aug 10, 2009 11:37 AM by SafeBoot

    Now this is really frustrating

      I used AD connector to sync the users. I am using autodomain to assign the users to the machine, when I log into the machine at OS level with AD account, the autodomain should process the user and should go through the user registration process. However, it does not. I can see the user assigned to machine after I log on with the AD user account, but at the pre-boot level it does not take the password of the user and I had to recover it.

      I looked at the AutoDomain log files and it is skipping to process all users who logs in at OS level with their AD account. Why is the autodomain skipping users, I cannot figure it out. Can anybody please help me out here

      here is how my INI file looks like specifically the skip user area
      ;ProcessUsers=current,cached
      ;SkipUsers= |Administrator|,|LocalService|,|All Users|,|Default User|,|NetworkService|,|Guest|,|systemprofile|,|emanager|,|$autoboot$|

      and here is the log file from the client machine

      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:Admin
      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:ScriptingUser
      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:meeadmin
      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:tien.wang11
      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:meeuser
      8/7/2009 10:08:27.43 AM: Found Currently Assigned User:meeuser3
      8/7/2009 10:08:27.43 AM: Skipping adding the following users for you because they are either already allocated, or on a blacklist your administrator has set:|Administrator|,|LocalService|,|All Users|,|Default User|,|NetworkService|,|Guest|,|systemprofile|,|emanager|,|Admin|,|ScriptingUse r|,|meeadmin|,|tien.wang11|,|meeuser|,|meeuser3|


      why |,|meeadmin|,|tien.wang11|,|meeuser|,|meeuser3| account are skipping, I need these accounts to be processed.

      Please please help.
        • 1. RE: Now this is really frustrating
          as it says, because they are already assigned to the machine.

          AutoD will only process users if they need to be assigned - in your case, they are already assigned, so either AutoD already did it, or you assigned them some other way, either by a group relationship between the machine and users, or you dragged and dropped them across.
          • 2. RE: Now this is really frustrating
            Actually , CheckCurrentUserList option must be set to False, by default it is set to true. It is working now as it should.
            --------------------------

            3.9 Option - CheckCurrentUserList
            Name: CheckCurrentUserList
            Section: Users
            Purpose: Flag to indicate whether to query the current user list of the machine prior to processing the local detected users.
            Default Value: True
            Range: True/False

            If True, the script obtains the current user list of the machine being processed, and adds those users to the local skip list. This prevents the script trying to create/assign users which already exist in the database.
            If False, the script attempts to process each user without any knowledge of whether they already exist or not.
            If in your situation, most users on most machines are unique, there is no need to pull the user list in advance (set this option false). If however many users are shared between many machines, this option can reduce the network load, as many unnecessary create events can be prevented by one call to obtain the current user list.
            • 3. RE: Now this is really frustrating
              I disagree - all you did by changing the CheckCurrentUserList is obscure the fact that the users are already set to the machine. CheckCurrentUserList should be set to true, because other wise users will get asked for their password every time they log onto a new machine (because the script won't know they have already been through the registration process).

              The root problem is still the same - you assigned the users to the machine PRIOR to AutoD running. Set up your machines without those users assigned, then AutoD will go through the personalization for the logged on user when it realizes they need to be set.

              trust me - I wrote AutoDomain happy
              • 4. RE: Now this is really frustrating
                I do trust you, but. then how do you explain this, even though the AskUserForPassword is true in the Autodomain INI file, users are not being asked for the password not even once to set the single sign on settings. Since I have all the users already synced with AD connector, so here is what is happening.

                A new user logs in to Windows who is already exists in the database via AD connector, not assigned to the maching yet

                The sync process occurs, the user is then assigned to the machine,

                After the reboot, the user logs in the with default password of 12345 at the PBA

                At the windows logon scree, the user logs in with the domain credential, the computer resyncs with the server, and the SSO details then set

                next time user logs in with the domain password at the PBA and SSO works at the windows logon.

                At no point at the running of the script, the user is being to ask for the password. The only time it happened via autodomain is when the users did not exist in the data based at all and the user is being created and assigned via autodomain by looking at the cached or currently logged on user.

                In my experience so far if the user does exist in the database and not yet assigned to the machine the autodmain does not give the pop up screen for the user to provide the windows credentials.


                • 5. RE: Now this is really frustrating
                  I do trust you, but. then how do you explain this, even though the AskUserForPassword is true in the Autodomain INI file, users are not being asked for the password not even once to set the single sign on settings.

                  >they won't be if they are already set to the machine. If you want the current user to be asked regardless of whether they are already set or not, use the "alwaysask... " setting.


                  The sync process occurs, the user is then assigned to the machine,

                  >how?


                  At no point at the running of the script, the user is being to ask for the password. The only time it happened via autodomain is when the users did not exist in the data based at all and the user is being created and assigned via autodomain by looking at the cached or
                  currently logged on user.

                  >because according to your log, they were already assigned BEFORE autod did its first run.

                  In my experience so far if the user does exist in the database and not yet assigned to the machine the autodmain does not give the pop up screen for the user to provide the windows credentials.

                  >but according to your log, they already did exist, and were already set. Are you SURE you have not made a relationship between some general user group and the machine group, and thus the users are already assigned to the machine from the moment it's created? For AutoD to work as you expect, you must let IT assign users.
                  • 6. RE: Now this is really frustrating
                    The user does exist in the database because of the AD sync process, but not assigned to the machine. Now, when this user who is already in the database and not yet assigned, logs into the machine at OS level NOT at the PBA since he cannot log at the PBA due to the fact that he is not assigned to machine. The autod kicks in for the newly logged on user, processed the user and syncs the machine and update the database by assigning that exsting user in database to the machine.

                    The only thing here autodomain is doing is assigning the existing user to the machine and not creating the new user. The SSO details are set the management center.

                    Now once the user is assigned to machine as mentioned above, the user reboots the machine and comes to the PBA. At that point user types in the username and the default password of 12345.

                    At windows Logon screen, SSO still not kicks in, user then type his AD credentials again, the MEE AutoD wizard run, or manually sync or automatically syncn what ever the case may be for syncronization the SSO information gets update and user PBA password then gets set to the AD password. So next time the user logs in he will be using the windows password at the PBA and he then gets log in at the windows automatically.

                    Any thougths?
                    • 7. RE: Now this is really frustrating
                      set alwaysask.. as true.

                      your log does not agree with your last post though - in the log the users were ALREADY assigned to the machine, prior to AutoD running.

                      Check your log on a clean run - it should show that autod set the user to the machine, the last one you sent me showed the user was in the skiplist, thus they were ALREADY assigned to the machine prior to autoD running.

                      that I think is where your root problem is.
                      • 8. RE: Now this is really frustrating
                        Ok, as you have suggested, I make the option, alwaysaskforpassword to true. This time when I logged in a with new user in the machine, the user that was already in the database but not yet assigned to the machine, it prompted the user for the AutodD prompted the user for the windows password. And after setting the password, for the very first time the PBA took the windows password and I was able to log in and SSO worked also. So it did work like it suppose to.

                        Hopefully it stays the same now. I will be testing some more machines with the same configuration and will update you.

                        Thanks for all your help
                        • 9. RE: Now this is really frustrating
                          R3k1awyk5
                          Rbashir --
                          When the users are added via the AD Connector, what user group are they being added to? Is that user group assigned to the machines in question? If so, the user is already assigned to the machine.
                          1 2 3 Previous Next