RE: Now this is really frustrating

[rbashir]

R3k1awyk5
The users are added in there own OU. The group that is created in the management consol reflects the OU structure in the AD. I have a template group created with all the settings that the new groups get created when the AD connector brings in the user. There is a setting in AD connector where you can define the new groups be based upon.

[SafeBoot]

you didn't answer the question 😉

what users/user groups are assigned to the machine group that you created your install set from?

[rbashir]

I am not assigning the whole user group to a machine. Only the individual users get assigned to machine once they log into the machine. I do have an administrative group with few admin users that are assigned to every machine group. We are in an environment where we do not have multiple users sharing the laptop. It mainly on one user per machine. The admin user group is there for support purposes.

I hope this answers the question.

[SafeBoot]

it still does not add up - the evidence from your log was that the users were assigned BEFORE autodomain ran. They were sitting there when it ran for the first time, that's how they got added to the skip list.

[rbashir]

I will email you the new logs tomorrow.

[rbashir]

I have just emailed you the new log file from autodomain

[SafeBoot]

the password you entered on the last run for rehan.bashier was invalid - ie it did not conform to the template you have set for the password policy in EEM, or it was in the history already etc. After a few tries you cancelled the prompt (or let it timeout).

is that the problem? If not let me know what problem you are trying to resolve now.

you are also not running the script with admin rights. I guess it's running under user rights? Mostly that won't be a problem but you should be aware of that.

S.

[rbashir]

Yes, that was a password template issue, it has been fixed now. Please excuse my ignorance here, but how do you run the script with admin rights, if a user is logging into the system with regular user account. I assume that autodomain will run with the account privilege based on user logging it. Regular user does not have the admin rights.

Is there any way to always run autod with admin rights?

Please advise

[SafeBoot]

very true. It will run under the user rights and the script is set to handle that as best it can.

you can pack the script with something like PrimalScript and give it a nominated account to run under if you want.

if you are not having any permissions issues though, leave it alone - the script has code to change some file/folder permissions when it installs.

[rbashir]

Ok, but here is another observation that I would like to share. I have set the option of CreateMachineinOU=True. Now, the AutoD created the OU structure with C: appended to it, which tells me that the OU group structure is created with Autod. However, I do have a :Endpoint Encryption Machines" template group that all other machine group shoule be based of off.


I do log into the machine with different accounts regular and admin, and I have noticed the machine jumps between the template group and OU group created by the Autod by itself. It does not remain in its OU all the time. What do you think is the porblem here. Is it something to do with user rights?