AD_AddUserToGroup

This workflow adds a specified user to an Active Directory group.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence.

The workflow is starting with a connection to the Active Directory server, by using the ConnectToAD activity:

Where:

ADPath represents the LDAP of the Active Directory server.
Username is the user that will connect to the Active Directory server and it can be manually inserted (with the Domain\Username format) or provided via a variable or an IN argument.
The Password Binding parameter has no default value because its value must be given encrypted when run outside the Designer (for example Flowster Studio - Portal).
The Password parameter is a Password editor type. When clicked, the Password editor opens and the user may specify the desired password.

The output of the activity will be reflected in the Connection (ADConn) variable and it will be used for the rest of the Active Directory activities as an input.

After the connection is made, the GetEntry activity will be used in order to retrieve the entry path of the user that will be added to the group:

Where:

Value is the sAMAccountName of the user. The input value is provided via argument ADUser_sAMAccount <String>.

The activity outputs the user entry path and is stored in the variable UserEntryPath <String>.

The next step of the workflow is to obtain the group entry path using the same GetEntry activity.

Where:

Value is the sAMAccountName of the group. The input value is provided via argument ADGroup_sAMAccount <String>.

The activity outputs the group entry path and is stored in the variable GroupEntryPath <String>.

The next step of the workflow is to add the user entry path to the group entry path using AddUserToGroup activity.

Where:

Group is the entry path of the group stored in variable GroupEntryPath.
User is the entry path of the user stored in variable UserEntryPath.

The workflow will finalize with a DisconnectfromAD activity:

AD_ListMembers

This workflow lists all users members of a group in Active Directory.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence.

The workflow is starting with a connection to the Active Directory server, by using the ConnectToAD activity:

Where:

ADPath represents the LDAP of the Active Directory server.
Username is the user that will connect to the Active Directory server and it can be manually inserted (with the Domain\Username format) or provided via a variable or an IN argument.
The Password Binding parameter has no default value because its value must be given encrypted when run outside the Designer (for example Flowster Studio - Portal).
The Password parameter is a Password editor type. When clicked, the Password editor opens and the user may specify the desired password.

The output of the activity will be reflected in the Connection (ADConn) variable and it will be used for the rest of the Active Directory activities as an input.

After the connection is made, the GetUsersInGroup activity will be used in order to retrieve a list of users members of a group:

Where:

GroupName is the name attribute of the group in Active Directory. The input value is provided via argument ADGroup_Name <String>.
Attributes represent the attributes that will be retrived for each user member of the group.

The activity outputs the list of users and their selected attributes in Output parameter and stored in variable MembersCollection <Collection<Collection<String>>>. The number of results are returned by Output Rows Count parameter and stored in variable MembersCount<Int32>.

Write activity is used to display at the end of the workflow execution the value stored in MembersCount

Where:

InputValue is the value that will be displayed in Tracking Data.

The next step of the workflow is to iterate through the MembersCollection to display the members returned by GetUsersInGroup activity.

MembersCollection is a variable of type <Collection<Collection<String>>>. In order to iterate each collection, two ForEach activities are required. The first ForEach activity will iterate through the main collection and it will be of type <Collection<String>>. The second ForEach activity will go through every subcollection of the main collection.
The Member attributes are displayed on every cycle of the ForEach activity

The workflow will finalize with a DisconnectfromAD activity:

Citrix_CreateVMfromTemplate_PowerOn

This workflow creates a virtual machine from a template. At the end of the workflow the new virtual machine is powered on.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence.

The workflow is starting with a connection to the Citrix XenServer server, by using the ConnectToXenServer activity:

Where:

Hostname or IP represents the Citrix Xen Server host.
Username is the user that will connect to the Citrix XenServer and it can be manually inserted (with the Domain\Username format) or provided via a variable or an IN argument.
The Password Binding parameter has no default value because its value must be given encrypted when run outside the Designer (for example Flowster Studio - Portal).
The Password parameter is a Password editor type. When clicked, the Password editor opens and the user may specify the desired password.

The output of the activity will be reflected in the Connection (XenConn) variable and it will be used for the rest of the Citrix Xen Server activities as an input.

After the connection is made, the VMCreateFromTemplate activity will be used to deploy a new virtual machine with a specified name from an existing template:

Where:

VM Name is the name of the new virtual machine. The input value is provided via argument VMName <String>.
VM Template is the name of the existing template. The input value is provided via argument VMTemplate<String>.
Start VM automatically is a drop down with default value Yes.

The activity outputs the UUID of the new virtual machine in variable NewVm_UUID<String>.

Write activity is used to display at the end of the workflow execution the value stored in variable NewVm_UUID:

Where:

Text is the value that will be displayed in Tracking Data.

The workflow will finalize with a DisconnectfromXenServer activity:

VMware_CreateVMfromTemplate_PowerOn

This workflow creates a virtual machine from a template. At the end of the workflow the new virtual machine is powered on.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence

The workflow is starting with a connection to the VMware vCenter, by using the

VMwareConnect activity:

Where:

Host Name represents the url to access vCenter server.
Username is the user that will connect to the VMware vCenter and it can be manually inserted (with the Domain\Username format) or provided via a variable or an IN argument.
The Password Binding parameter has no default value because its value must be given encrypted when run outside the Designer (for example Flowster Studio - Portal).
The Password parameter is a Password editor type. When clicked, the Password editor opens and the user may specify the desired password.

The output of the activity will be reflected in the Connection (VMConn) variable and it will be used for the rest of the VMware Server activities as an input.

After the connection is made, the VMGet activity will be used to obtain the Template ID:

Where:

Location represents the location of the template in vCenter.
VM Name is the name of the template. The input value is provided via argument VMTemplate <String>.

The activity outputs the id of the input template stored in variable Template_ID <String> .

Template_ID value will be used in the next step, DeployVMfromTemplate:

Where:

VM represents the template id that will be used to create the new virtual machine.
New VM Name represents the name of the new virtual machine. The input value is provided via argument NewVMName <String>.

The activity outputs the id of the new created virtual machine stored in variable
NewVM_ID <String>:

The final step in the workflow flow is to power on the new created virtual machine using VM Power On activity:

Where:

VirtualMachineID represents the id of the new created virtual machine.

Write activity is used to display at the end of the workflow execution the value stored in variable NewVm_UUID:

Where:

Text is the value that will be displayed in Tracking Data.

The workflow will finalize with a VMwareDisconnect activity:

HyperV_CreateVMfromTemplate_PowerOn

This workflow creates a virtual machine from a template. At the end of the workflow the new virtual machine is powered on.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence

The workflow is starting with a connection to the HyperV server, by using the

HyperVConnect activity:

Where:

Hostname or IP represents the HyperV server.
Username is the user that will connect to the HyperV server and it can be manually inserted or provided via a variable or an IN argument.
The Password Binding parameter has no default value because its value must be given encrypted when run outside the Designer (for example Flowster Studio - Portal).
The Password parameter is a Password editor type. When clicked, the Password editor opens and the user may specify the desired password.

The output of the activity will be reflected in the Connection (HyperV_Conn) variable and it will be used for the rest of the HyperV Server activities as an input.

After the connection is made, the CreateVMfromTemplate activity will be used to create a new virtual machine from a source template:

Where:

Source Template Name represents the name of the template. The input value is provided via argument SourceTemplate <String>.

VM Name is the name of the new virtual machine. The input value is provided via argument NewVMName <String>.

The activity outputs the status of the activity.

The next step is to power on the new created virtual machine using HyperVPowerOn activity:

Where:

VM Name represents the name of the new created virtual machine.

The workflow will finalize with a HyperVDisconnect activity:

Powershell_GetProcess

This workflow uses powershell scripts to output the result of the Get-Process powershell command.
General knowledge:

Annotations were used for each activity to explain the behavior of the activity
The main sequence used for this workflow is Flowchart Sequence

The workflow is starting with a powershell script code using PSscript activity:

Where:

Script code represents powershell code to be executed by PSscript activity.

The output of the activity is stored in ListProcesses<Collection<PSObjects>>.

The next step is to iterate through the collection of PSObjects in order to display the results of the powershell command using ForEach activity.

The Name property returned by the powershell command is evaluated with a Custom If activity:

In order to extract the Name property from the output returned and convert it to string, an Assign activity is used to store the Name property of the Process in ListProcesses collection:

The next step of the workflow is to get CPU property for the process with the name equal to the value stored in PSobj variable, using PSscript activity:

In order to output the values returned by Get CPU info activity, repeat the flow using ForEach activity.

Execution result:

Browser not supported