How to use vRealize Network Insight (vRNI) for application dependency mappings

vRNI can be a great tool in your networking and security operations arsenal, with loads of features to support your physical, virtual and cloud environments.

There is already a lot of great material available for vRNI but here are just some of the primary use-cases:

  • Plan Application security and migration
    • Micro-segmentation planning with automatic firewall rules recommendations.
  • Manage and Scale NSX
    • Multiple NSX Managers with proactive detection of misconfiguration errors
  • Optimize and Troubleshoot Virtual and Physical networks
    • Optimize application performs by removing bottlenecks
    • Audit network and security changes over time.

Also, the vRNI feature walkthrough page of VMware is excellent for an introduction

So back to why we are here! When you have a hybrid cloud strategy and have to move applications to the cloud you definitely want to know a couple of things:

  • Which VMs are sitting idle or are over-provisioned on resources?
    • vRealize Operations (vROps) should be your go-to tool to identify all these VMs
  • How much will cost to place my VMs into any of Cloud Solutions available out there, including VMC on AWS?
    • vRealize Business for Cloud should be your go-to tool to provide pricing for different cloud-based solutions on a selected VM/application.
  • If you have multi-tiered applications, do you know the dependencies between the VMs and on which port/s they communicate with?
    • There are a lot of tools available that can provide application dependency mappings, but for this exercise, we are just looking at vRealize Network Insight (vRNI).

Let’s look at the steps to create an application dependency mapping, which is very similar to the steps you will use to create your micro-segmentation firewall rules.

  • Step 1: Select the initial VM that you have identified for the application.
    • Using VRNI powerful search capabilities, type the query “VM where name = ‘vmname.’
    • For the duration, if you have collected information for a while, then select maybe the last 7 days as your time frame
    • Click Search
      • The VM can be selected in different ways like:
        • Path and Topology -> VM
        • Entities -> VM
    • Screen Shot 2018-04-24 at 4.26.28 PM.png
    • This will show information about the VM, click on the VM name.
    • Screen Shot 2018-04-24 at 4.29.37 PM.png
    • Click on Flows in the toolbar
    • Screen Shot 2018-04-24 at 4.30.20 PM.png
    • Review the VM Flows – Allowed and VM Flows – Denied
      • This shows all the flows to and from the selected VM
    • Click on the 3 vertical dots and select “Export as CSV.”
      • This exported document provides columns for all source and destination VMs that are connecting to your selected VM.  Use this to start your application dependency mapping by creating an application in vRBC.
        • Screen Shot 2018-04-24 at 4.39.50 PM.png
        • Select Entities -> Applications
          • Click Add Application
          • Enter Application Name
          • Enter Tiers and conditions to identify the VM or IP address
            • Add the VMs that you have identified as Source and Destination VMs in the flows.
          • You can also add more conditions to fine tune the VM select and also add additional Tiers.
          • Select Analyze Flows
          • Click Save
  • Step 2: Select the application, and add any additionally identified entities as the first hop.
    • Screen Shot 2018-04-24 at 4.57.18 PM.png
    • Select Security -> Applications
      • Screen Shot 2018-04-24 at 4.57.56 PM.png
      • Under scope drop-down select Application
      • Select Application name created in step 1
      • For Duration you can select anything but 7 days would be good to cover all different connectivity scenarios that might occur.
      • Click Analyze
    • On the Micro-segmentation view
      • Screen Shot 2018-04-24 at 5.01.34 PM
      • Under “Group By” select VM
        • Under “Also show groups for” select All
      • Under Flow, Types select “All allowed flows.”
      • Screen Shot 2018-04-24 at 5.30.36 PM
      • This will provide you with a presentation of how your application VMs are talking with one another
      • However, more importantly, you will see “other entities,” in grey boxes, which is what we are really interested in:Screen Shot 2018-04-24 at 5.38.54 PM
      • You can also filter based the groups to show all the entities associated with the groups below
        • Virtual
          • If you select virtual, you will be presented with a list of all the VMs that communicate to the applications, and have not yet been identified.
          • Again you export the CSV.
          • Review these VM’s and add them to the application.
        • Physical
          • If you select physical, you will be presented with a list of IP addresses for all the physical servers are you connecting too in your environment.
          • Review these VM’s and add the physical IP address to your application.
        • Shared Virtual
          • If you select Shared Virtual, you will be presented with a list of VMs that are connected to all the VMs in your application.
          • Review these VM’s and add them to the application.
        • Internet
          • If you select Internet, you will be presented with a list of public IP addresses that your application is connecting too.
          • Review these public IP addresses and take note of them
  • Step 3:  Manually create your application dependency mapping
    • If you really want to see how deep the rabbit hole goes then repeat step 2.
      • This will provide additional virtual, physical, shared and internet entities, based on the updated application.
    • Unfortunately is no way in vRNI to show a network connectivity diagram of the application like you were able to see in VIN so you would have to create your own Visio, making use of the flow diagram or exported CSVs to identify individual connectivity.

 

This is my own method and not sure if right or wrong, but if anyone has figured out a different or better way, please let me know!

Spectre and Meltdown – How to check your VMware environment for vulnerabilities

Updates added to the blog

Unless you have been on a very long vacation without internet access (The BEST type of vacation!) you should know of the Spectre (CVE-2017-5753 & CVE-2017-5715) and Meltdown (CVE-2017-5754) vulnerabilities that affect nearly every computer chip manufactured in the last 20 years.

I am not going to provide any specific details on these vulnerabilities since there are more than enough material already available, which you can read here:

I do however want to provide more detailed information related to VMware specifically, as well as different ways on how you can verify what in your VMware environment is vulnerable to these exploits:

VMware responded to the Speculative Execution security issues with KB 52245, which I highly recommend you read and subscribe to.

Intel and AMD released microcode updates that provide hardware support for branch target injection mitigation, for which VMware released KB 52085. The KB provides instructions on how to enable Hypervisor-Assisted Guest Mitigation, which is required in order to use the new hardware feature within VMs.  The KB also provides manual verification instructions for the following:

  • ESXi – Verify that the microcode included in ESXi patch has been applied
  • VM – Verify that the VM is seeing the new microcode ( VM needs to on HWv9 or newer)

ALERT: VMware also released KB 52345, which rollback the recently issued security patch recommendation (ESXi650-201801402-BG, ESXi600-201801402-BG, and ESXi550-201801401-BG). The rollback is due to customers complaining of unexpected reboot after applying Intel’s initial microcode patch on Intel Haswell and Broadwell processors.

UPDATE 01.24.18: VMware updated KB 52345 to include updated list of all Intel CPUs affected by Intel Sightings

  • VMware provides some manual workarounds for these specific processors that have already been patched.
  • For ESXi hosts that have not yet applied one of the patches, VMware recommends not doing so at this time and using the patches listed in VMSA-2018-0002 instead.

That is a lot of information to take in, and the rollbacks just add complexity to IT teams who are trying to secure their customer’s data.

UPDATE 02.15.18: VMware security advisory for VMware Virtual appliance mitigation available here

Option 1: (The best of the best)

However, to make things a bit easier we have William Lam to the rescue who wrote an excellent script that automates the verification for both the ESXi and Virtual Machines. as well as provide ESXi microcode versions.

The PowerCLI script is called VerifyESXiMicrocodePatch.ps1 and performs the following validations

  • Verify that VM’s are running at least HWv9
  • Verify that VM completed a power cycle to see the new CPU features
  • Verify ESXi microcode has been applied
  • Verify that one of the three new CPU features are exposed to the ESXi host.
  • Verify if CPU is affected by Intel Sighting
  • Show the current Microcode version for each ESXi (requires SSH to be enabled)
  • UPDATE 01.24.18: Script was updated to validated the affected CPUs

All the detail regarding the script can be read on virtuallyGhetto here.

Option 2:  (Acceptable, but limited)

Although not nearly as thorough as William’s Script, with RuneCast Analyzer latest 1.6.7 you can detect ESXi hosts that are not protected and patched against these vulnerabilities.

Runecast Analyzer enables you to scan and detect the CPU chip vulnerabilities on your VMware infrastructure.  It detects which ESXi hosts are not protected and advise on how to patch them against such security vulnerabilities.  This solution is continuously updated as new guidance from VMware is released.

Currently only supports VMSA-2018-0002.2

Update 01.26.18: New 1.6.8 release updated to support VMSA-2018-0002.3

Screen Shot 2018-01-18 at 6.34.09 PM.png

Update 01.21.18: Option 3: (Coolest of them all)

This option does not only show what in your VMware environment is impacted but it will also assess the performance impact of both Spectre and Meltdown patches using vRealize Operations Manager (vROPS). We already know the patches will impact the speculative execution capabilities of the processor, which will lead to higher CPU utilization in your cluster due to each OS slower processing times.

The questions that come up then before patching:

  • Will I have enough resources available in my cluster to support these patches?
  • How will my ESXi host resources be impacted?
  • Should I roll out the patches in stages or all at once?

These are hard questions that are not easy to answer, or is it?

If you are using vROPS 6.6.x Advanced or Enterprise, which allows the creation of custom dashboards, then you can download and install the Spectre Meltdown Specific Dashboard kit created by Sunny Dua.  The download is available here.

The Dashboard kit consists of 3 Dashboards:

Screen Shot 2018-01-24 at 10.59.56 AM.png

  • Performance monitoring dashboard
    • Track resources utilization of your environment and will provide valuable information on the impact of patching as it relates to your Clusters, ESXi hosts  VMs.
    • Screen Shot 2018-01-24 at 11.59.56 AM.png
  • VM Patching dashboard
    • Provides views showing which VMs are running idle and can potentially be patched first since it should not have a large overall impact on performance.  Evaluate the resource utilization with the performance monitoring dashboard after the idle VM’s are upgraded, and then make a decision to continue patching or first add additional resources to the cluster.
    • Screen Shot 2018-01-24 at 11.11.41 AM.png
  • vSphere Patching dashboard
    • Shows the ESXi hosts that have been patched and also affected by Intel Sighting.
    • Shows the ESXi hosts that still needs to be patched.
    • Show the Virtual Machines that required Hardware versions upgrade since the recommended version is 9 or higher.
    • I recommend keeping an eye on VMware’s advisory site since this problem is still ongoing and the build numbers will change as new patches are released.  This will then required that you make a manual update in the filters of this dashboard
    • Screen Shot 2018-01-24 at 11.51.08 AM.png

The Performance monitoring dashboard can also be accomplished by just using the default dashboards available in vROPS standard, which means you can download the evaluation version and have that piece of mind that you can track the performance impact while going through these tough times.

Links:

https://communities.vmware.com/message/2738226#2738226

https://blogs.vmware.com/management/2018/01/assess-performance-impact-spectre-meltdown-patches-using-vrealize-operations-manager.html

https://kb.vmware.com/s/article/2143832?r=2&Quarterback.validateRoute=1&KM_Utility.getArticleData=1&KM_Utility.getGUser=1&KM_Utility.getArticleLanguage=1&KM_Utility.getArticle=1

vRealize Network Insight (vRNI) 3.5 upgrade process that works

It is have been almost a year ago since my initial post on upgrading vRealize Network insight to 3.2 and since then there has been couple of new versions released. So time for me to upgrade!

The bad part I found out about the upgrade process is that you have to upgrade each version consecutively meaning I had to upgrade my 3.2 environment to 3.3 (which i am currently on right now) and then next step is to upgrade to 3.4 and following that another upgrade to 3.5.  You cannot skip version upgrades all!  Anyways, not going to comment on that but you see where this can be very time consuming so plan accordingly.

As before there are still two upgrade options available with online, which is handled through the GUI and offline, which is handled through the CLI.  I am currently running 3.3 and in the GUI under Settings -> Install it states that my Application is up to date. I did verify through CLI command “show-connectivity-status”  that my upgrade connectivity status shows passed and I also have no proxy.  Not wanting to open a support ticket I am going to go the manual route, and oh yes if you have a cluster configured, your only option is manual upgrade as well. Sorry!

Firstly we must upgrade the vRNI Platform appliances before we upgrade the Proxy appliances. If you have cluster then you have to start with platform1.  VMware’s KB on the manual upgrade process to 3.5 does not do such a good job of showing the exact steps to upgrade so here are mine:

  1. Download the upgrade bundle
  2. Extract the bundle from the downloaded zip file.
  3. Snapshot your vRNI Platform and proxy appliances before upgrade. (always have a backup)
  4. Login to Platform CLI with consoleuser
  5. Change password for the support user
    1. (cli) modify-password support
    2. Enter the password
  6. Use a popular tool like WinSCP to copy the bundle file to the all vRNI appliances
    1. Login with the support user
    2. Copy the bundle file in directory /home/support/
  7. Now we need to use the package-installer command to copy the bundle file to the vRNI VM
    1. package-installer copy –host localhost –user support –path /home/support/VMWare-vRNI.3.4.0.1495004044.upgrade.bundle
    2. Enter password
    3. Verify copied completed
    4. Remember one version at a time so first off have to upgrade from 3.3 to 3.4.
  8. Stop the service
    1. (cli) services stop
  9. Run the upgrade
    1. (cli) package-installer upgrade (3.3 -> 3.4)
    2. (cli) package-installer upgrade –name VMware-vRealize-Network-Insight.3.5.0.1502978926.upgrade.bundle (3.4 -> 3.5)
    3. This could take up to 30 minutes to complete so go have a cup of tea or coffee.
    4. Verify upgrade completed by checking the version
      • (cli) show-version
    5. If the service does not start..
      • (cli) services start
  10. Run step 4 through 9 on all appliances
    1. vRNI Platform appliances first
    2. vRNI Proxy appliances last

After the upgrade from 3.3 to 3.4, the upgrade KB states that a reboot is not necessary, but I found that if you do not perform a reboot you are not able to run the upgrade command “package-installer upgrade –name VMware-vRealize-Network-Insight.3.5.0.1502978926.upgrade.bundle”.  The –name parameter is not recognizable.

Note:

Do not copy/paste the commands in the KB since the filename is different that what you actually download “VMWare” and this make your upgrade fail.

Links:

 

 

 

 

Upgrading vROPS 6.x to 6.6.1

With all the new goodies in 6.6, especially the new HTML5 UI based on the Clarity design System, who can resist the upgrade to vROPS 6.6. Release notes for everything that is new can found here.

From an upgrade standpoint, vROPS has always been an interesting, but simple process with both the OS and application that requires separate updates.  The OS update is required for update RPMs for things like database and gemfire updates that the new vROPS application relies on.  My step by step upgrade guide below:

  1. Download the OS update and Product update files from my.vmware.com
    • OS PAK file:  vRealize_Operations_Manager-VA-OS-xxx.pak
    • Application PAK file:  vRealize_Operations_Manager-VA-xxx.pak
  2. Make sure that all the solutions you have installed has a version available that is compatible with the new vROPS release.
  3. If you customized any default alert definitions, symptom, recommendations, Policy Definitions, Views, Dashboards, Widgets and Reports in the previous version, make sure you clone it first.  When you upgrade vROPS, it is important that you upgrade the current versions of content types that allow you to alert on and monitor the objects in your environment.  It is a good practice to always clone first before customizing content.
  4. Before starting the upgrade, create a snapshot of the each of the nodes in the cluster.
    1. Login to vROPS admin
    2. Under system status click Take Offline
    3. Enter reason and click OK
    4. When Cluster status shows offline for all nodes, go ahead and take a snapshot of each
  5.  Before starting the upgrade, I also recommend taking a backup of all the nodes simultaneously by using your existing backup solution.
  6. First off we will update the Virtual Appliance OS:
    1. Login to the master vROPS node administrator interface
    2. Select Software Update
    3. Click Install a Software Update
    4. Browse the OS update PAK file
      • vRealize_Operations_Manager-VA-OS-xxx.pak
    5. Check the box “Reset Default Content”
      • As mentioned above make sure you have cloned all your customized content!
    6. Click Upload
    7. When completed click Next
    8. Accept EULA click Next
    9. Click Next
    10. Click Install
    11. This will update the OS on the Virtual Appliances and restart them.
  7. Secondly we will perform the vROPS product update:
    1. Login to the master vROPS node administrator interface
    2. Select Software Update
    3. Click Install a Software Update
    4. Browse the application update PAK file
      • vRealize_Operations_Manager-VA-xxx.pak
    5. Check the box “Reset Default Content”
      • As mentioned above make sure you have cloned all your customized content!
    6. Click Upload
    7. This will update the vROPS application on the Virtual Appliances
  8. Lastly, if you have any additional content packs installed, go ahead and upgrade them.

VMware is definitely making awesome improvements in all their products and has come a long way in helping out VMware admins with their daily management tasks.

SovLabs: Upgrading your software

SovLabs isn’t just a vRA plugin, it’s enterprise software that extends the capabilities of your vRealize Automation environment providing you with that end-to-end solution you have been craving for.  As with any other enterprise software they periodically provide new patches and releases and with SoLabs that is no different.

The new 2017.3.x was released in August and provides some awesome new modules:

  • Men & Mice DNS and IPAM
  • SolarWinds DNS
  • Backup as a Service
    • Automate policy-driven backups and provide self-service VM and file-level recovery for –
    • Cohesity
    • Rubrik
    • Veeam
  • SovLabs VM tagging
    • Drive rich metadata using VM tags and categories
  • SovLabs Property Toolkit
    • Manage your existing custom properties on VMs with the SovLabs Template Engine
  • ServiceNow Support for Jakarta
  • Puppet support for 2017.1
  • VMware Tools connection
    • Connect to Windows/Linux servers can now be done through VMware Tools which removes the requirement for WinRM, CygwinSSH or WinSSHD to be installed.  This is huge!
  • As a customer you can sign up under the self-service portal and view the detailed release notes here:

So how do we go about upgrading SovLabs to the latest version?

Step by step guide to upgrading from 2017.2.x to 2017.3.x.  (there are some additional steps if you are upgrading from <= 2017.1.x so please contact SovLabs support) 

  1. First off we want to create a backup of the vRO package
    1. Login to vRO Client
    2. Click Design
    3. Click on the package tab
    4. Click on the package icon on right hand side menu bar
    5. Enter name “com.sovlabs.backup.resources”
    6. Edit the newly create package, click on the pencil icon on the right hand side menu bar
    7. Click the Resources tab
    8. Click the Folder + icon
    9. Expand the Library folder,  select the SovLabs folder
    10. Click on the Select button
    11. Once loaded, click save and close
    12. Right click the saved package and click export package
      1. Create a folder called sovlabs under downloads
      2. leave the rest of settings as default
    13. Save to your local system
    14. Now, lets save the old SovLabs Plugin:
      1. Use WinSCP and login as root to vRO appliance
      2. Go to directory /var/lib/vco/app-server/plugins
      3. Save the o11nplugin-sovlabs.dar to your local file system in same sovlabs folder created earlier under download.s
    15. Done!
  2. We need to update the vRO Heap size
    1. If you have done this before then you can skip this step but this is needed to install the larger sized SovLabs module file into vRO otherwise the appliance might run out of memory during install/upgrade.
    2. Remember if you a vRO cluster, then you have to perform the steps on both server
    3. SSH into vRO appliance with user root
    4. Run # vi /var/lib/vco/configuration/bin/setenv.sh
    5. Find the #MEM_OPTS section
    6. Replace the -Xmx512m \ with -Xmx768m \
    7. Save the file
  3. Delete all SovLabs license keys
    1. Login to vRA tenant
    2. Click on Items tab -> SovLabs vRA Extensibility modules -> SovLabs License
    3. For each SovLabs License item listed
      1. Select Actions -> Delete License
  4. Download the SovLabs plugin
    1. Talk to SovLabs support about getting the software downloaded.
  5. Install the plugin into vRO appliance
    1. Login to controlcenter
      1. https://<vroserver&gt;:8283/vco-controlcenter
    2. Select Plug-Ins -> Manage Plug-ins
    3. Click Browse
    4. Select the plugin
    5. Accept EULA
    6. Click on Install
    7. Accept the EULA
    8. Restart the vRO server
      1. On the Home page, click on the Startup Options icon
      2. Click on Restart
      3. Wait for vRO to restart successfully
    9. Log back in to the vRO configuration page
    10. Click on the Manage Plug-Ins icon
    11. Verify that the installed plugin is listed among the vRO plugins
    12. Now if you have a clustered vRO 7.2 and above, then the plugin should sync but I have seen some problems with 7.2 so follow these steps
      1. Perform a full reboot on primary so that the pending and active config fingerprint ID match.
      2. Then push the config to the other standby node
      3. It will need to rebooted which it often will not do so make sure you perform this step yourself.
      4. Verify that Synchronization state shows synchronized and verify the version of the plugin on both active and standby nodes.
  6. Login to the vRO Client and run the configuration
    1. Click on Design mode
    2. Click on WorkFlow tab
    3. Right click vRO workflow, “SovLabs/Configuration/SovLabs Configuration”
    4. Select Start Workflow
    5. The SovLabs Configuration workflow only needs to be run on one vRO in a clustered environment
      1. Select yes to accept the EULA
      2. Click Next
      3. Select the appropriate tenant and business group
      4. Create SovLabs vRA Catalog Service? = No
      5. Publish License Content? = No
      6. Click Next
      7. Upgrade existing SovLabs vRA content? = Yes
      8. Click Next
      9. Install or Update SovLabs workflow subscriptions (vRA7.x)? = Yes
        1. *Enables vRA to call vRO during machine lifecycles
      10. Click Submit
      11. Verify that the SovLabs Configuration workflow completed successfully
  7. Lastly, let’s verify the SovLabs Plugin in vRA
    1. Select Catalog tab
    2. Verify that Add license -> SovLabs Modules catalog exists
  8. Now lets install the new license key for 2017.3.x
    1. This process has also been drastically simplified with a single license key which will license all modules, where previously this was done one at a time.
    2. Select Catalog tab -> SovLabs vRA Extensibility Modules -> Add license – SovLabs Modules
    3. Copy the text from license file and paste into field
    4. Click Submit
    5. Verify all catalog tab -> SovLabs vRA Extensibility Modules that all catalogs are available.
  9. If you ever need to roll back then follow the steps in the document provided by SovLabs:
    1. https://s3.amazonaws.com/docs.sovlabs.com/vRA7x/guides/SovLabs_BackupRestore-vROPackage.pdf

 

 

 

 

vRealize Automation: Request stuck in progress

I ran into an interesting problem today on my distributed (enterprise) vRA 7.2 environment and wanted to share how I got it resolved.

I have not deployed anything in my environment for a while but when I tried today my request was not completing and status is showing “In Progress”

Troubleshooting:

Review logs:

  • Infrastructure -> Monitoring -> Audit Logs
    • Machine requests shows that is was started
  • Infrastructure -> Monitoring -> Log
    • Found error on my manager services nodes “[EventBrokerService] Failed resuming workflow.. State VMPSMasterWorkflow32.Requested(POST). Event
      Event Queue operation failed with MessageQueueErrorCode QueueNotFound for queue ’30da8a16-c532-4e13-bd81-39b09114a887′.”
  • Logged into Service manager nodes and review the logs in Event Viewer
    • Found error “Error occurred while registering the DEM.
      System.Data.Services.Client.DataServiceTransportException: The underlying connection was closed: An unexpected error occurred on a send. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Authentication failed because the remote party has closed the transport stream”
  • Logged into the Web server nodes and review the logs in Event Viewer
    • Found similar error as above
    • Found error messages like “Error occurred writing to the repository tracking log”, “Error occurred while pinging repository”

Review DEM status:

  • Infrastructure -> Monitoring -> DEM status
    • both my DEM worker and Orchestrator shows with Status Active (Green)

Resolution:

I did some investigation and found really 2 problems that I needed to address

  1. If you find errors like “Event Queue operation failed with MessageQueueErrorCode QueueNotFound for queue” then you probably have manager service running on both instances (nodes).
  2. If you find errors like “System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it” then the problem is most likely with certificates and found in the vRA documentation that if you have commas in your OU section of the IaaS certificate, that your VM provisioning might fail and the following work around is provided
    1. Remove the commas from the OU section of the IaaS certificate, OR
    2. Change the polling method from WebSocket to HTTP to resolve the issues.
      • Open the Manager Service configuration file in a text editor.
      • C:\:Program Files (x86)\VMware\vCAC\Server\Manager Service.exe.config.
      • Add the following lines to <appSettings>
      • <add key=”Extensibility.Client.RetrievalMethod” value=”Polling”/>
        <add key=”Extensibility.Client.PollingInterval” value=”2000″/>
        <add key=”Extensibility.Client.PollingMaxEvents” value=”128″/>
      • Restart the manager services

Some other things to verify:

  • On Web server Windows OS nodes
      • Verify that the VMware Cloud Automation Center Management agent services is running
  • On Manager service Window OS nodes
    • Verify that the VMware Cloud Automation Center Service is running
      • This should only be running on 1 server if have a load balancer in front.
      • Set the Startup type to Manual on the 2nd server so you don’t have worry about this service starting but remember you have to failover manually by changing the service to automatic and starting the service.
        • In vRA 7.3 the failover process is now automated which is great!
    • Verify that the VMware Cloud Automation Center Management agent services is running on your instances
  • On DEM server Windows OS nodes
    • Verify that your VMware vCloud Automation Center Agent and Management agent services is running
  • Most people do not know this but VMware also has a very cool vRealize production test tool which I will blog about shortly.

Links:

https://docs.vmware.com/en/vRealize-Automation/7.2/com.vmware.vrealize.automation.doc/GUID-71F4F6F1-DBAE-4E0B-83A5-B4B25921B6A7.html

https://docs.vmware.com/en/vRealize-Automation/7.0/com.vmware.vra.extensibility.doc/GUID-7E54F8B9-9F76-4470-9B6F-6DAE5972E740.html

 

 

Adding Microsoft Azure to vRA and vRB Part #2

In part 1 I showed how to add Microsoft Azure to vRA.  In this part 2 I will show how to add Microsoft Azure with Non-EA account to vRealize Business which will provide cost information for your MS Azure account.

I have to apologies for taking so long to publish this but I had the blog written and ready to go but it was created with vRB 7.2, which had a lot of bugs with Azure integration  and the documentation was not very thorough and made use of the old Azure portal interface for configuration.  The problem I ran into can be view in the community post here, but with a lot of views and not responses I decided to wait until vRB 7.3 to review this again.

Prerequisites:

  1. You must have a Microsoft Azure Enterprise Agreement (EA) or non-EA account.
  2. If using MS Azure non-EA you must have one of the following credits offers:
    1. Pay-as-you-go
    2. MSDN
    3. Monetary commitment
    4. Monetary credit

To add a non-EA account you will also need the following information during configuration so please make sure you have this available.  I am also providing the steps on how to configure your non-EA account.

  • Client ID
    • When you register a client app, such as a console app, you receive a Client ID. The Client ID is used by the application to identify themselves to the users that they are requesting permissions from.
  • Location of Purchase
  • Tenant ID
    • Value can be retrieved from the Azure default Active directory when you select manage -> properties in menu.
  • Secret Key
    • Value will be defined during app registration.

Continue reading