Month: June 2017

vRA & SovLabs: vSphere DRS

/ johannstander / Leave a comment

This modules allows you to make use of VMware’s DRS to sub-divide your vSphere clusters for consumption by defining DRS groups, affinity and anti-affinity rules. A good use case for this would the deployment of a VM that needs to be tied to specific host due to licensing or hardware constraints, or VMs behind load balancers that you want to make sure run on different ESXi hosts.

The module has many features which can viewed on the website here, but some of the highlights are:

  • Create and manage vSphere DRS profile configurations directly in vRA and tie them to existing blueprints to enable affinity or anti-affinity relationships between VMs provisioned and existing DRS host groups.
  • Automatic cleanup of appropriate linked VM rules and groups during VM de-provisioning lifecycles
  • Allows for VM provisioning into specific pre-defined DRS host groups
  • Dynamically creates VM group(s) and rule(s) during VM provisioning based on the corresponding SovLabs DRS profile configuration

Prerequisites:

  • vCenter Server is properly configured
  • vCenter cluster is properly configured and the host groups defined

Configuration:

  1. Add vCenter Endpoint
    1. Login to vRA Tenant
    2. Select Catalog -> SovLabs vRA Extensibility
    3. Screen Shot 2017-04-18 at 5.08.40 PM.png
    4. Click Request button for “Add SovLabs vCenter Endpoint”
    5. Screen Shot 2017-04-18 at 5.10.07 PM.png
    6. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    7. Select vCenter version
    8. Enter PSC FQDN
    9. Embedded PSC = yes/no
    10. Enter vCenter Server FQDN
      • this should get populated
    11. Create credentials = yes
      1. This is not the vRA credentials so if you have not set this up through the catalog item request then you have to do so first.
    12. Enter username
    13. Enter password
    14. Click Submit
  2. Add DRS Profile
    1. Login to vRA Tenant
    2. Select Catalog -> SovLabs vRA Extensibility
    3. Screen Shot 2017-04-18 at 5.24.17 PM.png
    4. Click Request on “Add DRS Profile”
    5. Screen Shot 2017-04-18 at 5.24.51 PM.png
    6. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    7. Select vCenter Endpoint
    8. Select Cluster
      • If the clusters do not show up, make sure you have Host groups defined in DRS or that the credentials are entered correctly.  Credentials can be updated through the SovLabs Catalog “Manage Credential Configuration”
    9. Select host group
      • I create 2 hosts groups within the cluster, with separate hosts in each, which will be assignment to each blueprint.
    10. Select Rule
      • I selected should run on hosts in group
    11. Click Submit

 

Enable the module:

Now we need to enable the custom properties module on our blueprint

  1. Click on Design -> Blueprint
  2. Edit Blueprint
  3. Click on the blueprint vSphere machine on the Design Canvas.
  4. Click on properties tab
  5. In the properties group section click +Add
  6. Check the box for:
    • Check the appropriate vSphere DRS property group (starts with SovLabs-DRS-)
    • Do not attach more than 1 vSphere DRS property group to a vSphere machine blueprint
  7. Click OK
  8. Repeat these steps for all blueprints that should use this custom naming.

 

 

vRealize Business for Cloud 7.3 upgrade process

/ johannstander / Leave a comment

In my lab I am upgrading from vRB 7.1 to 7.3 using the Web console, so I will primarily be focused on providing steps for this scenario.  There are a couple of ways going about the upgrade for instance:

  • Web console
  • Downloadable ISO image through CDROM
  • Default or specific repository address
    • a Specific repository is useful when you update a specific version

Prerequisites:

  • Take snapshot of your appliance!
  • If using vRB with vRA, make sure you are on a supported vRA version ( => 6.2.4) before you start the upgrade.

Installation:

Disclosure: I am registered to vIDM. In the documentation is states if you are registered to vIDM that it is not necessary to unregister. Well I ran through the upgrade and it did not create the new groups in vIDM, to which you are suppose to assign your users for administrator access.   To fix this I had to unregister and register after the upgrade was completed. Let me know if it works for you with VMware steps but it certainly did not for me.  In the steps below I reference unregistering with vRA or vIDM.  Use at own risk.

  • Login to vRB VAMI
  • Select registration tab
    • Depending on your registration preference,  make sure to disconnect first to either vRA or vIDM.  (read my disclosure above since VMware docs only mention vRA)
    • Select either vRA or vIDM tab
    • Enter username and password
      • admin/password
    • Click Unregister
    • Verify unregister was successful
    • Screen Shot 2017-06-14 at 3.56.57 PM.png
  • Select Update tab
    • Click Check Updates
      • You should get a message that a new version is available.
    • Click Install updates
  • Update will start and appliance will automatically reboot

Verification:

  • After installation is complete
    • Login again to vRB VAMI
    • Click Systems
      • Verify new 7.3 version is shown.
    • Click Network
      • Verify Hostname is set to your server name, and NOT localhost
        • If it is set to localhost, select address tab
        • Enter server name within the hostname field
        • Click Save Settings
    • Select registration tab
      • Depending on your registration preference,  select either vRA or vIDM tab
      • Enter username and password
        • admin/password
      • Click Register
      • Verify Registration is successful

Post-upgrade configuration:

If you login now you will get errors like below.

Screen Shot 2017-06-14 at 4.27.58 PM.png

Screen Shot 2017-06-14 at 4.28.26 PM.png

The groups created in vIDM for vRB < 7.3 use to be:

  • VCBM_ALL
  • VCBM_VIEW

These will still be visible as groups in vIDM, but are not being used, since they have been replace with new groups:

  • vRBC_Administrator
  • vRBC_Controller
  • vRBC_ViewOnly

Modify the users for the new vIDM groups create for vRB

  • Select Users & Groups
  • Select menu Users in This Group
  • Click Modify Users in this Group
  • Create rule
  • Click Next
  • Verify users in list to be added
  • Slick Save

 

Now you can login successfully to vRB with vIDM registration and enjoy the new user interface and product features.

 

vRA & SovLabs: DNS module

/ johannstander / Leave a comment

DNS plays a very important role in making sure your deployed VMs are accessible, and if this is not configured correctly you can run into problems that can sometime be difficult to diagnose.

SovLabs modules make sure that no stale, duplication or orphaned DNS records exist which is great since we have all had those days where we are to lazy to unregister a VM from AD before we delete it, right!?

SovLabs also supports DNS integration with Infoblox, Bluecat and BT Diamond IP which is very helpful since these might be used for different departments and give you that flexibility to accommodate those scenarios.

For this blog I am focusing on using just the regular old Microsoft Active Directory.

The module has many features which can viewed on the website here, but some of the highlights are:

  • Handles simple to complex globally distributed multi-zone, multi-site MS DNS environments
  • Employs several methods to improve DNS data integrity and mitigate issues from stale, duplicate or orphaned DNS records, such as retry logic, record availability and DNS propagation/post validation checks
  • DNS configurations are interchangeable between endpoint providers; avoid lock-in by easily adding additional DNS providers with other DNS modules from SovLabs
  • Allows for independent configurations for forward and reverse records, if desired
  • Supports up to 10 network interfaces per machine

 

Prerequisites:

  1. Identify the Domain Controllers to be used, or if policy dictates no direct connections are allowed then identify a proxy server.
    • If using a proxy server then make sure the environment setup is complete by following these steps
  2. If you are not using the SovLabs IPAM module, then you need to make you sure you set the DNS suffix within your network profiles that will be used.
  3. Setup WinRM
    • WinRM must be enabled for SovLabs modules utilizing any Windows servers in the environment (for AD, DNS, IPAM, Puppet and etc.)
    • Follow these steps
  4. Install AD Webservices on all the DC’s that will be used.
  5. Verify NTP settings

 

Configuration:

  1. Add Microsoft Endpoint
    1. This configuration was covered in my previous post which can be viewed here.
  2. Add DNS configuration
    1. Select Catalog -> SovLabs vRA Extensibility
    2. Screen Shot 2017-04-18 at 3.54.05 PM.png
    3. Click Request on “Add DNS Configuration – SovLabs Modules”
    4. Screen Shot 2017-04-18 at 3.54.56 PM.png
    5. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    6. Domains
      • Add all the domains for this DNS config
      • Enter name
      • Press Green plus sign
    7. Networks
      • Add all the networks for this DNS config
      • Enter name
      • Press Green plus sign
    8. DNS server type
      • MS DNS in my case
    9. DNS server endpoints
      • Select the one that was previously created
    10. Create A record = yes
    11. Create PTR record = yes
    12. Use a default server
      • Can specify this server if no match on domain and network.
    13. Screen Shot 2017-04-18 at 4.08.46 PM.png
    14. Click Submit

 

Enable the module:

Now we need to enable the custom properties module on our blueprint

  1. Click on Design -> Blueprint
  2. Edit Blueprint
  3. Click on the blueprint vSphere machine on the Design Canvas.
  4. Click on properties tab
  5. In the properties group section click +Add
  6. Check the box for:
    • SovLabs-EnableLifecycleStubs
  7. Click OK
  8. Repeat these steps for all blueprints that should use this custom naming.

Now deploy a VM and watch the magic happen.  The provisioned VM will automatically attempt to register with Microsoft DNS only if the VM is in the configured domain and network defined for Microsoft DNS.

Disable the module:

If you have the DNS module installed but for some reason are not using it or need to disable it then following the steps below:

  • If you do not have the DNS module configured, and try to deploy a catalog item, you will get an error like “Error: DNS Registeration could not find a DNS Configuration for the Hostname and/or IP of <servername> / 192.168.1.10 (Workflow:DNS machineBuilding / Add DNS (item10)#65)”
  1. Click on Design -> Blueprint
  2. Edit Blueprint
  3. Click on the blueprint vSphere machine on the Design Canvas.
  4. Click on properties tab
  5. Click on Custom Properties tab
  6. Click +New
    • Name = “SovLabs_DisableDNS”
    • Value = “true”
  7. Click OK
  8. Click Save
  9. Repeat these steps for all blueprints that should use this custom naming.

Links:

http://docs.sovlabs.com/vRA7x/current.html#microsoft-dns

http://docs.sovlabs.com/vRA7x/current.html#infoblox-dns

http://docs.sovlabs.com/vRA7x/current.html#bluecat-dns

http://docs.sovlabs.com/vRA7x/current.html#bt-diamond-ip-dns

 

VMware announces general availability for all vRealize Suite Standard products!

/ johannstander / Leave a comment

VMware has already been teasing us since June 6th with the upcoming releases of the following vRealize Suite products:

Today VMware announced GA for all products mentioned, with what seems to be a unified message to provide one integrated architecture, with greater/deeper integration across SDDC technologies and multiple public clouds.  I like where this is going…

Couple of key take aways for me which are shared amongst some of the products (not all):

  • Redesigned HTML5 UI
    • Log Insight jumped on this long ago.
  • OOTB Integration between the different products
    • We have started seeing this with previous release but not going into full swing
  • Standardizing on authentication with VIDM

Release notes for each product:

 

Hopefully I can make some time in the upcoming weeks to dive a bit deeper into some of the features, but due to my busy schedule I am not holding my breath 🙂 Happy downloads!

SovLabs: Microsoft Active Directory module

/ johannstander / Leave a comment

Windows servers require Microsoft AD, it is an integral part of the server architecture. I am not going to get into much detail on the directory service since this blog is focused on how SovLabs interacts with it.

The module has many features which can viewed on the website here, but some of the highlights are:

  • Handles simple to complex globally distributed multi-domain, multi-site MS AD environments
  • Registers/cleans computer account with Active Directory
  • Supports placement in a “build OU” during provisioning in order to facilitate software deployments/configurations that require a less restrictive Group Policy
  • Supports dynamic creation and removal of OUs
  • Employs several methods to improve reliability of registration/cleanup to mitigate failures, such as retry logic and post validation checks

 

Prerequisites:

  1. Identify the Domain Controllers to be used, or if policy dictates no direct connections are allowed then identify a proxy server.
    • If using a proxy server then make sure the environment setup is complete by following these steps
    • Windows 2012 R2 required
  2. Setup WinRM
    • WinRM must be enabled for SovLabs modules utilizing any Windows servers in the environment (for AD, DNS, IPAM, Puppet and etc.)
    • Follow these steps
  3. Install AD Webservices on all the DC’s that will be used.
  4. Verify NTP settings
  5. “Shell access type” for the user account with permissions must be set to Command Prompt.

 

Active Directory Example:

I am going to initially deploy the computer object in the following OU which is used for pen testing: (BUILD OU)

  • OU=vra_BuildDeployment,OU=Servers,OU=Lab,DC=sovsys,DC=com

Then after pen testing is completed, I will move the computer object to the following OU:

  • OU=vra_Deployment,OU=Servers,OU=Lab,DC=sovsys,DC=com

Since I have production and development(lab) environment I would like create the computer object in different OUs.  This I can handle through a custom property and SovLabs Template engine.

SovLabs.AD.Environment.OU        –       defined on Business group

This will update my OU to following:

  • OU=vra_BuildDeployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
  • OU=vra_Deployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com

 

Configuration:

  1. Add Microsoft Endpoint
    1. Login to vRA Tenant
    2. Select Catalog -> SovLabs vRA Extensibility
    3. Screen Shot 2017-04-18 at 2.41.33 PM.png
    4. Click Request button on “Add Microsoft Endpoint”
    5. Screen Shot 2017-04-18 at 2.41.53 PM.png
    6. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    7. Select connection method
      • Select how the SovLabs modules will connect to the target or proxy Microsoft server
    8. Enter hostname
      • FQDN of AD server
    9. Use non-standard ports = no
    10. Is a proxy host = no
      • for my instance I am connecting directly to the AD server.
    11. Enter username and password
    12. Advanced configuration is only necessary when local administrator access cannot be given to the service account.
      • temporary directory = blank
      • share path = blank
    13. Click Submit
  2. Add Active Directory Configuration
    1. Select Catalog -> SovLabs vRA Extensibility
    2. Screen Shot 2017-04-18 at 2.52.13 PM.png
    3. Click Request on Add ActiveDirectory Configuration
    4. Screen Shot 2017-04-18 at 2.53.03 PM.png
    5. Enter configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    6. Select Microsoft Endpoint
      • created earlier
    7. Select Computer name case
      • Choose whether or not the computer name added in AD is all uppercase or lowercase
      • If you are using the Puppet module set this to lowercase since it will cause problems with authentication due the certificates created for the Puppet agent is always in lowercase.
    8. Use Build OU
      • Select yes if computer needs to be placed in an interim OU.
      • If yes, fill in create and remove OU, otherwise leave those blank.
      • OU=vra_BuildDeployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
    9. OU
      • ActiveDirectory Organizational Unit (OU) in DN format for computer/VM to join
      • OU=vra_Deployment,OU=Servers,OU={{SovLabs.AD.Environment.OU}},DC=sovsys,DC=com
    10. Security Group
      • List all AD security groups the server should join
    11. Delete computer account
      • If you select yes it will try to find computer account and delete it, regardless of which OU it is in.
    12. Screen Shot 2017-04-18 at 3.23.05 PM.png
    13. Click Submit

 

Enable the module:

Now we need to enable the custom properties module on our blueprint:

  1. Click on Design -> Blueprint
  2. Edit Blueprint
  3. Click on the blueprint vSphere machine on the Design Canvas.
  4. Click on properties tab
  5. In the properties group section click +Add
  6. Check the box for:
    • SovLabs-EnableLifecycleStubs
    • Microsoft Active Directory property group (starts with SovLabs-AD-)
    • Do not attach more than 1 Microsoft Active Directory property group to a blueprint vSphere machine object.
  7. Click OK
  8. Repeat these steps for all blueprints that should use this custom naming.

 

Now deploy a VM and watch the magic happen. Effortless, predictable, consistent and best of all no manual input of placing the created computer object in a specific OU.