Jan 01

UPDATED FOR VRA 7: How bout we let users set their default admin or root password?

Well happy new year and welcome to 2016! Between automation releases and cloud native applications activity, it’s going to be a very exciting year for all of us in IT.

Ever since I posted it, the “How bout we let users set their default admin or root password?” (use this for v 6)3 has been one of the most popular hits. Thankfully it has stood the stand of time through the last 2 years of vRA 6. Now that vRA 7 is here and more importantly the Event Broker, it’s time to document an updated workflow.

So let’s jump right in, there are a couple of pre-reqs that I’m assuming

  1. You have already setup vRA 7
  2. vRO (embedded) is setup as an Orchestration endpoint
  3. vCenter has been configured in vRO and vRA
  4. Downloaded my new vRA 7 ready Event Broker example package
  5. A linux or windows catalog item to provision


First we log into the vRO client and go to the EB Set Admin Password Example and open the Schema tab. Here you’ll see a simple 5 step workflow that does all the work to set the admin passwords.


Now let’s walk through each step, starting with the Collect vRA Payload script. I go to the Visual Binding to illustrate the variable handling.


Next we look at the Scripting tab and you can think of this as the old workflow template which is where we’ll pull in and create any logic. Here we pull out the OS, the Password, and the VM name to use in the next step.


Next step in the workflow is to get the VM by name. In this example I’m just showing you that I copied the out of the box workflow (no customization) and am passing the VM name to the criteria input for that workflow.


Next we’ll open the Convert to VC:VM and go to the Visual Binding tab to illustrate we are taking the output from the virtual machine by name and converting it to a single object.


In the scripting tab we pull the array value from “vms” and push it to the “vm” object, we also build the logic to execute the specific guest commands based on the operating system.


Final step for the workflow is to put the Run program in guest (again no customization of this standard workflow).


And now for the last piece within vRO, you will need to edit in your environment if you choose to use this workflow. You will need to set your default password which we use to login and run the commands to set it to the user requested password.


Now let’s go log into vRA web interface go to Administration -> Events


Subscriptions -> New


In this workflow we’ll use Machine Provisioning


Select Run based on conditions, All of the following, expand Data and select Lifecycle state name


Set it control to Equals and in the 3rd box hit the drop down to see the list of events. As you can see this list is very robust! Scroll all the way down to VMPSMasterWorkflow32.MachineActivated


Next we repeat the above steps choosing Lifecycle state phase, Equals, and POST.


Next we select our EB Set Admin Password Example workflow


Set a timeout and check blocking


Now we select the subscription we created and publish it


Now we just need to created the password box during request time. Administration tab -> Property Dictionary


Then Property Definitions -> New


Name is what we collect in the workflow, label is what the  users sees, and the rest of these are pretty self explanitory.


Finally we assign the custom properties to the blueprint. Design tab -> Blueprints -> Select your blueprint to edit


Select the VM -> Properties tab -> Custom Properties. You will just plug in the property which will be available via drop down, and slect to have it to show in request.

Then create the extendingclouds.os and assign a value of Linux or other

And create the following property which passes all of these properties at a very specific time. I’ll cover these details in my Event Broker post.

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineActivated and set the value to * so every value gets passed


Now request your VM and watch the magic!!!


As I stated through this post we will be doing a number of posts about this new Event Broker because of it’s power and flexibility so stay tuned!








Skip to comment form

    • Adrian on April 19, 2016 at 8:57 am
    • Reply

    Hey, Gary!

    Thank you for the great post! I found it really helpful while building my vRA infrastructure.
    I was wondering whether is it possible to customize your workflow to change a non-root password at the same time as well? (assuming that a Linux desktop template will have a general user).


    1. Adrian, Absolutely it’s pretty simple to execute a change of the user password too. You will want to make a duplicate of my workflow and alter the scriptable tasks where it defines the command to run (ie you won’t want to pass the root user) and the pass variable will likely need to be changed (unless you are going to use the same password for the user that you are prompting for in the form). Then you can follow the guide to create another event subscription at the same point. Both will run and the one with the lowest priority will execute first. Hope that helps!

        • Adrian on April 19, 2016 at 11:35 am
        • Reply

        Actually, I was a bit lazy so I made it as a one-liner (since in my template both, the general user and the root has the same password). So I modified only this line:
        arguments=’-e “root:’ + pass + ‘ncloud-user:’ + pass + ‘” | chpasswd’ ;

        Another thing what I am recently trying to achieve is to somehow provide a hint (or info) for the vRA users when entering a password. Let’s assume that, like in your post, I can provide a way to enter admin/root password. A more desired option is to require some password complexity which can be easily achieved via regex (like in your post for vRA6.x). However, if not satisfying the regex, the only thing the user will get is a ‘Regular expression validation failed’ error window. Is there a way to create self-defined information bubbles/windows? Or at least to provide a small information message for password requirements when hovering the mouse cursor over e.g. a field?

        Anyway, thank you for your advice! Will definitely try as well. Looking forward to excellent posts like this one 🙂

        1. Adrian,

          Sadly with 7.0 we lost the RegEx option so there still some catch up that we have to do. That said if you’re using the property definitions to create the properties you can do things like put requirements in the description and hope the user reads them. Alternatively you could use XaaS to create and request the blueprints and build the form very specifically to your needs, this would allow you to put those type of details into the request form.

            • Amir A. on May 13, 2016 at 6:32 pm

            Hi Gary – thanks for this great post. I second Adrian’s comment above and I was looking exatly the same thing. I was able to use property definitions to add some texts for the password requirement and stuff on the request page. But I noticed that RegEx is not supported to add password complexity requirement. That’s kind of bummer since that was present in prior versions. Hope there will be other ways to achieve that, without being frowned upon our security team for loosening up the password requirements on the templates :).

          1. Amir, Yes I understand your frustration and quite frankly have already started that battle internally. I can’t promise it will be back in Q3 but I have a feeling the next .1 release will include the regex on the forms like we had in v.6

            Alternatively you could implement a work around that used vRO scriptable task to validate the field during the Requested-Pre stage and fail the build if it doesn’t meet your criteria. It wouldn’t feel like a great user experience but could be something as a stop gap.

            • Amir A. on May 23, 2016 at 9:57 am

            Gary – actually that what I just did (using a VRO workflow and EB), at least in the lab and will replicate that to prod. However, I am just forcing the deployment to fail and currently it doesn’t have a notification as to why the deployment fail. I am looking into polishing the vRO workflow to send out email to owner, which is giving me the opportunity to learn vRO one workflow at a time :).
            Thanks again.

    • Adrian on May 25, 2016 at 6:18 am
    • Reply


    I am still trying to resolve somehow the password complexity validation limitation. Recently I have decided to generate a one-time password for the VM requester which will be sent to her/him via email (nothing better came to my mind). However, I do not know how to share a variable among different workflows in vRO. E.g. I would like to generate a password in the set admin password workflow you posted in january, and later (in a diferent time) grab this password and send it via your send custom email workflow. I could not find anything usable over the Internet. Do you have any idea how to overcome this issue?

    1. As far as I know there are only 2 ways to do this, 1 is to write a temporary file to the vRO file system. Which is how I will do it in my next post or to use a configuration element. In all honesty neither of these scale well at all.

        • Adrian on May 25, 2016 at 2:19 pm
        • Reply

        I chose the temporary file and managed to send the generated passwords via customized emails. If you think my workflows can help to accelerate your work, I can share them with you. Anyway, thanks again.

        1. Thanks I’ve already got that working so we are good. I would encourage you to take any content you create and if possible put it out on developercenter.vmware.com I’d like to see us build a strong shared community so in the future we can all build off of one another1

    • Radin Hairul Anwar on November 13, 2016 at 9:40 pm
    • Reply

    Hi, I’m using your script to password value for my Windows Machine, but I got this error :
    cannot call method “get” of null. what seems to be the problem ya?

    1. Radin, This appears to be an issue with getting the values for your machine request. Make sure that the property values are set on the blueprint. There should be an OS property and a property for the on provisioned. You can also look at this updated package to make life easier.

    • Adrian on November 22, 2016 at 8:48 pm
    • Reply

    Hi All,

    did anybody try to password set/change script on Windows10 or Server 2016 machines? The script works fine in older Windows versions, but in these new versions, it does not change the password, i.e. the workflow succeeds, but the password is un-set/-changed.

    Any experience?

      • Kirill on December 26, 2016 at 3:10 am
      • Reply

      I try this workflow with MS Server 2016. All ok. I don’t see any problems, but looking for any password complexity validation for windows.

      1. Depending on your version of vRA you won’t be able to implement that in the request portal. You will either need to do it as a vRO workflow or through XaaS form. I believe 7.2 includes RegEx again

      • Adrian on August 31, 2017 at 6:37 pm
      • Reply

      Hi All,

      after taking a break for a year, I gave another chance to password change in Windows 10. Since it took me a while to identify the source of the problem and resolve it, I thought, those who are still struggling with W10 password change could find helpful if I will share my solution here (I hope you do not mind Gary).

      In W10 the NET command requires elevated command prompt mode, ie, you have to run it as an Administrator. However, in W10 admin account is deactivated by default. In addition, even if you activate it in your reference machine (template), the Sysprep procedure resets it to the default deactivated mode (when you are cloning it in vRA [actually vCenter]). So when vRO workflow tries to change the password, it will fail (a standard user account with administrator privileges is not suitable for password change).

      To resolve the issue:
      – first, you have to force W10 to activate the administrator account when finishing Sysprep. For this task, you can use the procedure in KB2034622 (do not forget to set a password and check your Customization Specification (CS) in vCenter as well — by mistake, I kept overwriting this password with the one I forget to change in the CS).
      – then, in the workflow, you will connect to the VM using the Administrator account instead of the standard user account.
      – at last, in the workflow, you first set the user password using the administrator account and then deactivate it (the admin account).

      I hope someone will find this method helpful (or at least it will help to get closer to a solution).

  1. Gary,

    The workflow works great on ms-windows machines, but I get the following error when trying to run the workflow against PhotonOS

    Failed to authenticate with the guest operating system using the supplied credentials. (Workflow:Run a program in guest / Scriptable task (item1)#15)

    1. If I recall correctly the Photon authentication system was different as it used the change on first boot method.

      I think to accomplish this you would need to run install the photonOS, set your desired password then clone to template so you could log in. I would also validate that you have ssh service started as well as verifying passwd command works.

  2. Hi Gary – just followed your tutorial on a semi fresh vRA 7.2 installation (lab) with integrated vRO. Blueprint deploys but the root password is not set at all. Where do I start w/ troubleshooting? Thanks a ton! Great blog!

    1. I would go step by step through the workflow process and review the results of the system logs. You should see the results in the workflow logs that will tell you if there were any failures. If there were no failures I would log into the linux system and try to run the same command to validate that they do work with your OS version (some might vary a bit). Let me know if you have more troubles I could look hop on an try to help.

Leave a Reply

Your email address will not be published.

%d bloggers like this: