Local Windows runtime user?

[STOps9487]

Is there a way to use a local windows account as a runtime user?

I have tried to create a windows runtime user, but domain is a required field, and if I use the local machine name as the domain, the validation fails, I assume because it's trying to query AD for the machine names domain.

Is there another way to create a runtime user for a local windows account?

[Shaun Roberts]

Hi Andrew,

I have been able to do it before using a "\" for the domain but that was a while ago. *However* know that CPO does not support local users and requires a domain. So if you did get it to work it would be an unsupported setup. CPO does not support workgroups or local users. (just like it's not supported in windows 7, but you can install it and it can run)

If you do get it to work, it would only work for the single local CPO instance. You could not use a local user on another(or remote) box for example.

If this is some functionality you want, I would suggest a TAC case and ask to raise this as an enhancement.

[meisenst]

People have gotten it to work using synchronized usernames/passwords (same local username and password on both the PO machine and the remote machine), but as Shaun said, this would not be a supported way to do it.

[pawel.baran]

Hi Shaun,

Any idea if something has changed in CPO 3.0 as per support for local users?  I am trying to execute PS script on standalone server where one of my commands is adding server to damain.

Have tryied that "\" workaround but still getting error while creating WIndows user in CPO :(

[Shaun Roberts]

Pawel,

 As per my above statement. We never supported local users so whether it is in 3.0 or 2.X does not matter. People tended to get them to work because you could get around in a non HA/non 3.0 environment. Now with security even at the AD level, it's just not something that should work. Again it's not supported but if it's a feature you want/need you should raise a TAC case and have the enhancement added or at least your company added to the list that wants it.

Like Mike said you can try having the SAME username and SAME password on a user but that's highly dangerous and I doubt MS would say it's a best practice.

On adding to the domain, can you not do it via VMWare adapter via the Customize OS activity? I believe that has a domain piece in it. Or can you execute the command on a domain box but in the script target the remote box you are adding? (or something to that affect)

If none of these are options and you really must have local user support then I suggest a TAC case->Enhancement route.