vcloud director customization script context

[raelyard]

via customization script, i am trying to do several things on new windows server 2008 r2 instances in my vcloud environments.  i am launching powershell via the postcustomization call and most of what i am trying to do works, but i am having some problems and would appreciate some information and/or help.

notably, i am trying to install the microsoft distributed transaction coordinator, and that just doesn't seem to work.  i have had problems with my template having dtc pre-installed and want to install it after starting up.  this is something that doesn't require powershell, but i'm trying to do it from my powershell scripts that are doing a lot of other things as well.

if i just issue:

msdtc -install

i get a failure stating that msdtc can't be found (even if i specify the whole path, same thing: "The term 'C:\Windows\system32\msdtc.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.").  when executing the same scripts from an interactive command prompt after the instance has started, everything succeeds.  this leads me to believe that perhaps there is something related to the context under which the customization script runs that is somehow nonstandard and doesn't include the system path or something of that sort.  perhaps related to the credentials under which the script executes.

i have also tried to execute my scripts via starting a new process to execute my scripts under Administrator credentials.  i thought that maybe changing the context by getting it to run under a different user would help.  something along the lines of (via powershell):

$password = ConvertTo-SecureString "#####" -AsPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential (".\Administrator", $password)

start-process powershell -Credential $credential -ArgumentList '-NoProfile -File .\Setup.ps1

this also works just fine when i execute in an already running instance from a command prompt.  it executes when i run it via customization script, but the artifacts created by my setup script do not appear, so i assume it just didn't execute.  i've tried many variations of this with simpler commands than my script and can't get any powershell to execute this way.  every time i can execute manually without any problem, but can't get it to work on creating a new instance with a customization script.  this also doesn't on postcustomization but does when i'm logged in:

start-process powershell -Credential $credential -ArgumentList '-noprofile -noexit -noninteractive -Command "& {ls > C:\test.txt}"'

so my question has several parts:

1. how can i get my script to do something like install msdtc?

2. what is the context under which customization scripts run?  please include information about user and anything else that makes the context unique and different than executing my script while logged in.

3. is it possible to launch a seperate process using powershell via customization script?  should it work as i'm doing it?  what am i doing wrong?

any information would be greatly appreciated.

dave

[aneverov]

Hi Dave,

What version of VCD are you running? It's better to always mention that since there are differences between implementations. I believe in 1.5 both pre- and post-customization script were executed from the context of Tools Service. By default it is "NT Authority\System". To confirm just run something like:

if "%1%" == "precustomization" (

whoami >> C:\pre.txt

) else if "%1%" == "postcustomization" (

whoami >> C:\post.txt

)

You can change Tools Service's account to say local Administrator and that should change output of the above.

In 5.1 I changed post-customization to run after the last reboot in most cases. That was needed in order for folks to plug their own hooks and know when customization is "done". It's implemented using Windows Task Scheduler. Now I believe the task is currently always executed as "SYSTEM", meaning that you would always get "NT Authority\System" in post.txt. And I've also seen some weird behavior related to the context stuff with other things like KMS activation.

I just had an idea - could you try to run your experiments using pre-customization together with changing Tools Service's account? If that works for you, I can think how to provide the same possiblity for post-customization going forward.

/Andrii

[raelyard]

thanks for the information Andrii.

i am using VCD 5.0.  there is something in the works to upgrade, but it is not going to happen quickly.

i am about to try the things you suggest and will respond with the results.

[raelyard]

both pre and post do indeed run under "nt authority\system".  when i change the credentials of the tools service to the local administrator, pre runs under local administrator and post still runs under system.

executing my msdtc install in the pre under the administrator credential does not help (which surprises me).

i've noticed that now with the tools service running under administrator, the logging to the customize-guest file is now split between 2 files, one in the C:\windows\Temp directory i have been seeing and one in C:\Users\Administrator\AppData\Local\Temp, seemingly split between the pre and post customization stuff.  not that that really matters.

i have a few other ideas i am working on trying with some other powershell tricks.  any further suggestions would be great.

[raelyard]

so i've found that the user under which the scheduled process runs does not matter.  i have been able to reproduce the problem without having to stop my instance and restart with customization.

in the log output i found the command used to schedule the postcustomization on system startup (thanks for logging that).

C:\Windows\system32\schtasks.exe /create /sc ONSTART /rl HIGHEST /np /z /v1 /ru SYSTEM /tr "C:\Users\ADMINI~1\AppData\Local\Temp\vmwEACB.tmp\customize-guest.exe post-reboot" /tn "VMware Guest OS Customization Task"

by scheduling this myself, i can manually execute it.  sure enough, i get the same problem, even logged in and manually executing from the task scheduler user interface.  it seems my problem has to do with the context of executing my script via the customize-guest.exe rather than executing it directly.  if i use the task scheduler to schedule executing my script instead of executing the exe that then executes my script, it works.  i think i can work around all this by using the guest customization script to schedule an execution of my script i ultimately want to execute rather than trying to execute it directly.  it would be ideal not to have to do this, but in theory it should work.  i'll give this a try and report back.

[aneverov]

Hmm...

Yes, you're right - that's the way we schedule task in VCD 5.1. "/ru SYSTEM" (which means "NT Authority/System") is currently hard-coded. That's why Tools Service's account is not applied for post-customization.

However, as you pointed out, it could be that something gets screwed when we spawn "cmd /c script.bat". We schedule customize-guest.exe instead of script because of some weird caveat - even though we provide /z and /v1 as documentation says, the task doesn't get deleted. Which means it will execute again after each next reboot. So, we have to delete it ourselves once the script is executed from customize-guest.exe.

I'll check process management code. Maybe I can find something there.

/Andrii

[raelyard]

thanks very much Andrii.  you have educated me greatly.  my workaround is successful and i'm able to schedule my scripts in the same way you are scheduling the post reboot exe call.  i feel like i now have a much greater understading of what is happening.  i still can't explain why my script doesn't work the context of running through your executable, but i'm willing to let that go.  your help is appreciated.

my belief and my reading of the documentation on why the /z doesn't cause the task to be removed automatically is that it is still scheduled to run.  /z says to delete it "after its final run."  when it is scheduled to run on system startup, that means it hasn't hit its final run, so it doesn't self delete, it remains scheduled for the next system startup.  you may be saying that you think /v1 should mean it's scheduled to run only once.  if so, that doesn't seem to be the case - looks like it's for backward compatiblity with older versions of windows.

anyway, thanks very much.  if you do find something about what is unique in that context when executed from customize-guest.exe, i'd be interested to hear.  i am ok for my purposes now, though.

[aneverov]

Hi Dave,

I'm glad you aren't blocked anymore. Scheduling your own task seems reasonable enough for now. In VCD we'll continue scheduling customize-guest.exe instead of the script itself in order to delete the task until we find a better way to do it. This will make sure your task doesn't get scheduled twice.

It's a pain, so I won't let it go. But I don't have a better solution right now either. I can't see anything obviously wrong with the process management code. Anyway, it's already on my todo list and I've got some good ideas from this discussion. So, hopefully I get it fixed at some point.

Thanks for your patience. I know customization has always been a pain. But we have to support so many OS flavors and apply workarounds for sysprep and other weird stuff. If you get to the point you need features we don't provide, there are ways to extend it. It's not a rocket science. Just post a question and I'll provide guidance.

/Andrii

[raelyard]

understood.  having an abstraction like that over such diverse implementations has many challenges.  one suggestion that comes to mind would be to use a script rather than the exe (of course i don't know everything happening in the exe and maybe it is needed).  perhaps the exe could do less - only what really needs the exe and a script could drive the flow of calling the exe and the custom scripts.  of course, i'm speaking from ignorance of everything that is going on in there, so maybe my suggestion doesn't make any sense, but it's a thought.  again, thanks for the help.

[aneverov]

Technically it doesn't have to be exe. Although some parts of the platform today are hard-coded to name "customize-guest.exe" - but that's very easy to change. The primary reason it stays like that is because we run exact same exe across all Windows (including 2000, XP, etc.). So, we can't simply switch to say PowerShell (not supported on older OSes) or Java/Perl (would require users to install run-time which not everybody likes). However, it doesn't mean that there can't be alternative implementations which could be easily dropped in instead of our legacy beast. Like if you only care about w2k8r2+ and/or willing to install run-times - there is no reason that won't work. If somebody creates open source project with a friendly license, I would be happy to provide "thoughts" about what the architecture should be.

/Andrii