Squidly_Man's Posts

This post will walk you through the very basics of using Postman to use the VMware Identity Manager REST APIs to either GET or POST data. This post assumes either VMware Identity Manager 2.8.x... See more...
This post will walk you through the very basics of using Postman to use the VMware Identity Manager REST APIs to either GET or POST data. This post assumes either VMware Identity Manager 2.8.x on-premises tenant or newer or a VMware Identity Manager SaaS tenant. NOTE: Some additional API calls may ONLY exist for on-premises tenants (e.g. node health status, etc.) which may not be accessible for VMware Identity Manager SaaS tenants. The Basics: On some occasions, customers may need to have a resource send a command to VMware Identity Manager but then redirect back. By default, VMware Identity Manager does not do redirects (this is by design), however, it can support them with a slight modification to trusts.  The changes are a one-time change per VMware Identity Manager tenant and remain from that point forward unless removed by an administrator. In this example, we are showing the settings to both GET and POST updates to the "Allow Redirects" API, which tells the VMware Identity Manager what 3rd party sites the vIDM tenant is allowed to safely redirect a user to. Warning/Notice! Download 3rd party software at your own risk!  VMware does not assume responsibility or liability for your actions on any system or your use of 3rd party software or any damages which may be caused through the use of third party software. Prerequisites: Postman - If you search for Postman, you'll likely come to the Download Postman App web page (This is the primary source as far as I can tell). A VMware Identity Manager tenant.  Preferably a test tenant (DO NOT TEST ON A PRODUCTION TENANT!). Admin credentials to the VMware Identity Manager (TEST) tenant Getting the Bearer Token from the HZN Cookie in the Browser The following are the instructions for grabbing the bearer token from the HZN cookie and then applying using Postman to access the APIs to update the settings for allowing redirects. NOTE: Most modern browsers have an inspection mode.  Usually this is accessed by right-clicking on the web page and selecting INSPECT. Open a browser such as Chrome and authenticate as admin account to your Workspace ONE tenant (Note: Make sure you have the option to view the Administrator console). Open INSPECT mode in the browser by right-clicking on the page and selecting INSPECT from the context menu. Select APPLICATION from the inspection window. Select your Workspace ONE / VMware Identity Manager portal under cookies. Find HZN under the name column and copy the value data to your clipboard. In step 5.) of the below instructions, paste the token in for authentication as a Bearer Token. Using PostMan to access Workspace ONE APIs to GET Values When you define the parameters in PostMan, make sure the following are set. Start with GET command to test URL. URL to the API with correct FQDN of VMware Identity Manager tenant.  In this case, to read the “allowedredirects” value from the Workspace ONE tenant, use the below URL. https://<FQDN>/SAAS/jersey/manager/api/authsettings/allowedredirects Open Authorization tab… Set authentication type to BEARER TOKEN. Paste in token from HZN cookie from browser (see above procedure to get token from HZN cookie). When you press SEND, the Body value should appear as shown in the image below. Using PostMan to access Workspace ONE APIs to POST Values When you define the parameters in PostMan, make sure the following are set. Start with POST command to test URL. URL to the API with correct FQDN of VMware Identity Manager tenant.  In this case, to update the “allowedredirects” value from the Workspace ONE tenant, use the below URL. https://<FQDN>/SAAS/jersey/manager/api/authsettings/allowedredirects To note: Allowed redirects are per tenant (not per node within a tenant) so they only need to be set using the LB FQDN (e.g. portal.flaming.ws or workspace.mydomain.com). Open Authorization tab… Set authentication type to BEARER TOKEN. Paste in token from HZN cookie from browser (see above procedure to get token from HZN cookie). Switch to the HEADERS tab in Postman. For updating the allowedredirects value we need to add in the “Accept” header with the following value: application/vnd.vmware.horizon.manager.authsettings.allowedredirects+json For updating the allowedredirects value we need to add in the “Content-Type” header with the following value: application/vnd.vmware.horizon.manager.authsettings.allowedredirects+json NOTE: If you do not see the above image, you are likely in Bulk Edit mode.  If you’d like, you can just paste in the text per the next image, or shift to the Key-Value Edit mode in postman to see the above screen. Within Postman, switch to the Body tab. Select “raw” for the entry type. This allows you to type in whatever code you wish. Select the code type.  This is optional as TEXT or TEXT PLAIN will also work.  The code we are entering is JSON so either TEXT/TEXT PLAIN or JSON will work. Enter the following code.  PUT YOUR CAREGATE LOGOUT/LOGIN PAGE AND ANY OTHER PAGES IN COMMA SEPARATED FORMAT BETWEEN THE DOUBLE QUOTES.  ENSURE YOU ADD THE ASTERISK AT THE END OF EACH TO BE ABLE TO POINT TO ANY SUBPAGE. Single Site Code Example: { "allowedRedirects":["https://www.flaming.ws*"] } Multi-Site Code Example: { "allowedRedirects":["https://www.google.com*,https://www.flaming.ws*"] } When you press SEND, the pages you define will show up under “allowedRedirects” within the Body outcome. NOTE:  If you make an error, just correct it and repost the update. If you wish to remove all redirects, simply delete all web sites between the quotes and POST the update. Remove All Redirects Code Example: { "allowedRedirects":[""] } Conclusion: This should get you started with using Postman to use the REST APIs within VMware Identity Manager / Workspace ONE to help with better administering and programmatically calling for information and updates to/from Workspace ONE. For a list of VMware Identity Manager APIs, see the VMware Identity Manager API explorer on code.vmware.com.
This document is to assist with upgrading on-premises VMware Identity Manager appliances, including both the full on-premises appliance (commonly known as the Single Virtual Appliance - or SVA) a... See more...
This document is to assist with upgrading on-premises VMware Identity Manager appliances, including both the full on-premises appliance (commonly known as the Single Virtual Appliance - or SVA) and the on-premises standalone connector for a SaaS VMware Identity Manager tenant.  It should be used with the official VMware Identity Manager upgrade documentation (NOTE: Select the version of the appliance you are upgrading to from the drop down menu). Please note there are links embedded throughout the document below in reference to the documented procedures or other information. NOTE:  Document updated for VMware Identity Manager 2.9.x, 3.x, 19.03, and 20.01 as well as references for 2.8.x and older appliances. Index: You will find the following info within this document. Prerequisites: Prerequisites for an online upgrade Documentation: SaaS On-Premises Connector 2.8 Upgrade Docs 2.9.1 Upgrade Docs 2.9.2 Upgrade Docs 3.1 Upgrade Docs​ 3.2 Upgrade Docs​ 3.3 Upgrade Docs​ 19.03 Upgrade Docs​ 20.01 Upgrade Docs If on VMware Identity Manager 2.7.x or older and attempting to upgrade to 3.0, upgrade to 2.8.x/2.9.x prior to upgrading to 3.0. Upgrading from 2.7.x or earlier directly to 3.0 is not supported. If on VMware Identity Manager 3.0/3.1 and attempting to upgrade to 3.3, upgrade to 3.2.0.1 prior to upgrading to 3.3. NOTE: You may use the online upgrade documentation to upgrade to a specific version rather than having to download and do an offline upgrade to said version. Performing an Online Upgrade to a Specific Version (for SVA) Performing an Online Upgrade to a Specific Version (for Standalone SLES Connector) Verify that at least 4 GB of disk space is available on the primary root partition of the virtual appliance. Take a snapshot of your virtual appliance to back it up. For information about how to take snapshots, see the vSphere documentation. If you are using an external database, take a snapshot or backup of the database. This is only necessary when upgrading the Service (SVA) nodes. It is not necessary when upgrading a standalone connector. See the Microsoft SQL documentation on how to conduct a manual backup of a SQL database. Verify that VMware Identity Manager is properly configured. Verify that the virtual appliance can resolve and reach vapp-updates.vmware.com on port 80 over HTTP. If an HTTP proxy server is required for outbound HTTP access, configure the proxy server settings for the virtual appliance. See Configure Proxy Server Settings for the VMware Identity Manager Appliance. Confirm that a VMware Identity Manager upgrade exists. Run the appropriate command to check for upgrades. See Check for the Availability of a VMware Identity Manager Upgrade Online. If using a cluster AND upgrading to a version prior to 2.9.1, prepare the RabbitMQ Server before upgrading - See the Preparing RabbitMQ Server Before Upgrade procedure. If using a cluster AND upgrading to 2.9.1 or newer, note that RabbitMQ is disabled in 2.9.1 and higher. See the Upgrading a Cluster procedure in the documentation for whichever version you are upgrading to. Prerequisites for an offline upgrade​ Documentation: SaaS On-Premises Connector 2.8 Upgrade Docs 2.9.1 Upgrade Docs 2.9.2 Upgrade Docs 3.1 Upgrade Docs​ 3.2 Upgrade Docs​ 3.3 Upgrade Docs​ 19.03 Upgrade Docs​ 20.01 Upgrade Docs Verify that at least 2.5 GB of disk space is available on the primary root partition of the virtual appliance. Take a snapshot of your virtual appliance to back it up. For information about how to take snapshots, see the vSphere documentation. If you are using an external database, take a snapshot or backup of the database. Verify that VMware Identity Manager is properly configured. Confirm that a VMware Identity Manager upgrade exists. Check the My VMware site at my.vmware.com for upgrades. Prepare a local Web server to host the upgrade file. See Prepare a Local Web Server for Offline Upgrade​ document in whichever version of documentation you are upgrading to. Post-requisites:​ Documentation: SaaS On-Premises Connector 2.8 Upgrade Docs 2.9.1 Upgrade Docs​ 2.9.2 Upgrade Docs 3.1 Upgrade Docs​​ 3.2 Upgrade Docs​ 3.3 Upgrade Docs​ 19.03 Upgrade Docs​ 20.01 Upgrade Docs The following are settings to configure after the upgrade completes successfully. If you have set up a VMware Identity Manager cluster for failover, updating it to three nodes is recommended. This is because of a limitation of Elasticsearch, a search and analytics engine embedded in the VMware Identity Manager appliance. You may continue to use two nodes but you should be aware of a few limitations related to Elasticsearch. See "Configuring Failure and Redundancy" in Installing and Configuring VMware Identity Manager for more information. Enable the new portal user interface. In the administration console, click the arrow on the Catalog tab and select Settings. Select New End User Portal UI in the left pane and click Enable New Portal UI. Transport Layer Security (TLS) protocol 1.0 is disabled by default in VMware Identity Manager 2.8 and higher. TLS 1.1 and 1.2 are supported. External product issues are known to occur when TLS 1.0 is disabled. Updating your other product configurations to use TLS 1.1 or 1.2 is recommended. However, if your version of products such as Horizon, Horizon Air, Citrix, or load balancers have a dependence on TLS 1.0, you can enable TLS 1.0 in VMware Identity Manager by following the instructions in Knowledge Base article 2144805. After upgrading to 2.8.x, 2.9.x, or 3.x, set the thread count in the system config parameter, /SAAS/jersey/manager/api/systemconfigparameter/bulkSyncSharedThreadCount in all nodes and restart the node. Tips and Best Practices: Backup of IFCFG-ETH0 Make a copy of the IFCFG-ETH0 file before upgrading. Login to the appliance console or remote in as SSHUSER and then SU to root. Run the following command to make a backup of IFCFG-ETH0. cp /etc/sysconfig/networking/devices/ifcfg-eth0 /etc/sysconfig/networking/devices/ifcfg-eth0.bak Exit the console or SSH session. exit VM Snapshot Backup Make a VM snapshot before upgrading (no memory state needed unless you want one). Login to vSphere or vCenter. Browse to the VM in question. Right click on the VM and select options to create a new snapshot. Database Backups or Snapshots When upgrading the full VMware Identity Manager on-premises single virtual appliance (SVA), when taking a VM snapshot of appliance(s), it is also good practice to take a backup of the database or VM snapshot of the database server. Online Updates and Proxy Settings When doing an online update, you may need to set an outbound proxy within the appliance in order for it to reach the Internet and download the update packages.  Essentially the appliance must be able to reach vapp-updates.vmware.com on TCP port 80 (HTTP).  The latest instructions for setting a proxy for online upgrade can be found in the VMware Identity Manager Documentation online. The procedure for setting a proxy is as follows: Log in to the VMware Identity Manager virtual appliance as the root user. Enter YaST on the command line to run the YaST utility. Select Network Services in the left pane, then select Proxy. Enter the proxy server URLs in the HTTP Proxy URL and HTTPS Proxy URL fields. Select Finish and exit the YaST utility. Restart the Tomcat server on the VMware Identity Manager virtual appliance to use the new proxy settings by typing the following command: service horizon-workspace restart Post-Update Apply Hot Patches Apply any necessary hot patches after upgrading. The Upgrade Process The short version of the over-the-air procedure is… Login to the appliance console and make a backup of IFCFG-ETH0. Make a backup of /etc/sysconfig/networking/devices/ifcfg-eth0. Login to the appliance console or remote in as SSHUSER and then SU to root. Run the following command to make a backup of IFCFG-ETH0. cp /etc/sysconfig/networking/devices/ifcfg-eth0 /etc/sysconfig/networking/devices/ifcfg-eth0.bak Exit the console or SSH session. exit Make a VM snapshot (no memory state needed unless you want one). Login to vSphere or vCenter. Browse to the VM in question. Right click on the VM and select options to create a new snapshot. If you have a cluster of on-premises VMware Identity Manager full appliances (SVA) version 2.8 or older, you will need to prepare the RabbitMQ server on each. NOTE: Skip this step for VMware Identity Manager On-premises Connectors. If using a cluster AND upgrading to a version prior to 2.9.1, prepare the RabbitMQ Server before upgrading - See the Preparing RabbitMQ Server Before Upgrade procedure. Stop RabbitMQ nodes on each VMware Identity Manager appliance in the cluster. Type rabbitmqctl stop. Do this for each RabbiMQ node in the cluster before continuing. Verify that RabbitMQ is detached from the cluster. Type rabbitmqctl cluster_status. NOTE: In the above image, we see the running_nodes lists only node 1, so this means nodes 2 and 3 are not running RabbitMQ (yet). If using a cluster AND upgrading to 2.9.1 or newer, note that RabbitMQ is disabled in 2.9.1 and higher. See the Upgrading a Cluster procedure. Perform an Online Upgrade: Log in to the VMware Identity Manager virtual appliance as the root user. Run the following updatemgr.hzn command. /usr/local/horizon/update/updatemgr.hzn updateinstaller Run the following command to check that on online upgrade exists. /usr/local/horizon/update/updatemgr.hzn check Run the following command to update the appliance. /usr/local/horizon/update/updatemgr.hzn update Messages that occur during the upgrade are saved to the update.log file at /opt/vmware/var/log/update.log. Run the updatemgr.hzn check command again to verify that a newer update does not exist. /usr/local/horizon/update/updatemgr.hzn check Check the version of the upgraded appliance. vamicli version --appliance The new version is displayed. Check that IFCFG-ETH0 is present and properly configured. If not, copy or move the backup of the file to the original or recreate the original using VI editor with the contents of the backup. When done in VI, save the changes. mv /etc/sysconfig/networking/devices/ifcfg-eth0.bak /etc/sysconfig/networking/devices/ifcfg-eth0 Restart the virtual appliance. Type reboot Validate the upgrade works properly after the reboot. If you have a cluster of on-premises VMware Identity Manager 2.8.1 and older nodes, validate the RabbitMQ cluster status is good​. As each node is upgraded, run the rabbitmgctl cluster_status command on the upgraded node to verify that all the nodes upgraded so far are listed in the running_nodes section of the output. After upgrading node 1, the running_nodes section lists only node1. After upgrading node 2, run the rabbitmqctl cluster_status command on both nodes and the running_nodes section should each list node1 and node2. This indicates that the RabbitMQ nodes are clustered together correctly. When all nodes are upgraded, RabbitMQ forms a cluster with the 2.8.x (or older) nodes in the correct order. If you have a cluster of on-premises VMware Identity Manager 2.9.1 and newer nodes, the Upgrading a Cluster procedure to ensure RabbitMQ is disabled. Shut down each appliance within the cluster and boot each one up one at a time - waiting until the app server is fully started before booting the next.  After this is done, you should see all nodes in the cluster properly sync and go green. After upgrading 2.8.x or 2.9.x, set the thread count in the system config parameter, /SAAS/jersey/manager/api/systemconfigparameter/bulkSyncSharedThreadCount in all nodes and restart each node. See the online documentation for how to adjust this parameter correctly. Apply any post-upgrade patches if you have any to apply in accordance with their instructions. Delete the VM snapshot after a couple of days or if you are certain the upgrade process was successful. Upgrade Issues and Troubleshooting Options: Troubleshooting Upgrade Errors UpdateInstaller Fails to Run on VMware Identity Manager On-Premises Full Appliance Symptoms: Update, Update Check, Update Installer fail to run and/or show any outcome. Cause: Not enough available inodes (number of allowed files). Correction: Run df. This will give you an idea of how much space you have. Run df -i.  This will tell you how much inode space you have left. Example: If /var says 100% and you see inodes has less than 200 then you may have this issue. NOTE: An upgrade from VMware Identity Manager 2.6 to 2.7 typically requires around 209 inodes. The solution is to clear off enough files to free up enough inode space. NOTE: This can be done in any folder where there are enough files to make a difference. The recommendation is to use the /var/log folder as this is commonly the offender for inode consumption. To clear off bz2 log files more than 90 days old, do the following: Login to the appliance console directly (via vCenter) or via SSH (and SU to root). Browse to the /var/log folder cd /var/log Find and delete bz2 files older than 90 days.  The below command deletes anything ending with the extension “bz2” which is older than 90 days from current date. You may need to delete more recent files to clear up enough inodes by changing the time frame to a lower range such as 45 days instead of 90 days. find ./*.bz2 -mtime +90 -exec rm {} \; Retest update installer, update check, and update. /usr/local/horizon/update/updatemgr.hzn updateinstaller /usr/local/horizon/update/updatemgr.hzn check /usr/local/horizon/update/updatemgr.hzn update Reference: Information courtesy of Wibowo Leksono UpdateInstaller Reports No Updates on VMware Identity Manager On-Premises Connector Appliance Version 2016.11.1.0 Symptoms: Update Installer runs on VMware Identity Manager On-Premises Connector Version 2016.11.1.0 but reports no updates are available. Cause: Known Issue with VMware Identity Manager Connector version 2016.11.1.0. Correction: Apply VMware KB 2149179​ Reference: https://kb.vmware.com/kb/2149179 No Networking Detected on Reboot After Upgrade Link:  Networking Error after Upgrade Symptoms: The upgraded SUSE appliance shows NO NETWORKING DETECTED errors.  Logging in and looking at /etc/sysconfig/network (ls /etc/sysconfig/network -l -a) shows source file for ifcfg-eth0 is missing in /etc/sysconfig/networking/devices/ for /etc/sysconfig/network/ifcfg-eth0 link file. Cause: Known Issue with upgrade process wiping ifcfg-eth0 information Correction: Move the backup of ifcfg-eth0 taken during step 2.2 of The Upgrade Process back into place. Login to the appliance console or remote in as SSHUSER and then SU to root. Run the following command to move the backup of IFCFG-ETH0 into place mv /etc/sysconfig/networking/devices/ifcfg-eth0.bak /etc/sysconfig/networking/devices/ifcfg-eth0 Exit the console or SSH session. exit Alternately (instead of step 1.), manually create the file. Login to the appliance console or remote in as SSHUSER and then SU to root. Open the VI editor and create the file by typing the following command. vi /etc/sysconfic/network/ifcfg-eth0 Type in all of the settings as shown in the below reference image. All lines except IPADDR=, NETMASK=, and BROADCAST= will be identical to what is in the image.  To find your IP address, either ping or attempt to resolve the FQDN of the appliance to get the IP address, or look within the vApp advanced options of the VM to get the exact IP address.  From there you should be able to fill in the below values. IPADDR=‘<your_appliance_ip_address>’ NETMASK=‘<your_appliance_ip_subnet_address>’ BROADCAST=‘<your_appliance_ip_broadcast_address>’ Exit the INSERT mode by pressing the ESC key. Save the file and exit the VI editor by typing `:` (colon) then `x` (lower case "x") and then pressing the ENTER key. Reboot the appliance by typing reboot and pressing ENTER. Reference Image:
Introduction: The document will walk you through the setup of a custom F5 BIG-IP Health Monitor for use with VMware Identity Manager appliances when acting as nodes in a cluster. Background... See more...
Introduction: The document will walk you through the setup of a custom F5 BIG-IP Health Monitor for use with VMware Identity Manager appliances when acting as nodes in a cluster. Background: In previous versions of documentation from VMware and F5 which discussed clustering of VMware Identity Manager with F5 BIG-IP load balancers, it was suggested to use the `http_head_f5` health monitor.  However, due to security updates within VMware Identity Manager 2.8 and higher, the use of the aforementioned F5 BIG-IP health monitor is no longer a viable option.  Because of this, many customers were using the `gateway_icmp` F5 health monitor as a temporary workaround. Unfortunately, this would allow the F5 BIG-IP to see a node as good even though it may only be responding to a ping, resulting in traffic failures and web pages failing to load for end users.  Therefore, a better health monitor needed to be used. Solution: Working together, VMware and F5 come up with a validated custom health monitor using built-in VMware Identity Manager APIs to determine if the node (or appliance) in question is properly responding. The basic F5 health monitor information is as follows: Send String: GET /SAAS/API/1.0/REST/system/health/heartbeat HTTP/1.1\r\nHost: <LB_FQDN>\r\nConnection: Close\r\n\r\n NOTE: Remove the "<>" if you copy/paste into your health monitor. Receive String: ok$ Receive Disable String: 404 Creation Procedure: Here is how to create this within the F5 BIG-IP. Login as administrator to your F5 BIG-IP appliance. Browse to Monitors under the Local Traffic tab in the left hand menu. Click the CREATE button in the upper left to start the creation of a new health monitor. Give it a name such as ViDM_Monitor or something similar and provide a description as needed. Select HTTPS as type.  This will set the parent monitor to https and open up the "Configuration" screen with options for Send String, Receive String, and Receive Disable String among the many shown. Use the following for the Send String. GET /SAAS/API/1.0/REST/system/health/heartbeat HTTP/1.1\r\nHost: <LB_FQDN>\r\nConnection: Close\r\n\r\n NOTE: Remove the "<>" if you copy/paste the above line into your BIG-IP settings. Use the following for the Receive String. ok$ Use the following as the Receive Disable String. 404 Leave the rest of the fields as their default settings. Click the FINISHED button. Now you need to assign this to the VMware Identity Manager Pool for the F5 BIG-IP virtual server to utilize. NOTE:  Make sure you do this part during off-hours or scheduled down time. Assuming you are already logged in from above, browse to Local Traffic > Virtual Servers > Pools and select your pool of VMware Identity Manager appliances. Edit the Health Monitors section to remove previous active health monitors and assign your new health monitor you just created above. Click the UPDATE button when ready. Validate the new health monitor works properly and as expected by viewing the pool members status and Virtual Server status within the F5 BIG-IP admin console. Conclusion: Now you can rest assured the F5 BIG-IP is properly monitoring your VMware Identity Manager cluster to determine which nodes are live and which are not! Acknowledgements: Big thanks to F5's Matt Mabis for helping us work through these settings and to VMware's Michael Almond and Karen Zelenko for guidance and support in testing this. Document was edited by Dean Flaming April 26th, 2017 to correct the Receive String when heartbeat is not showing "ok" and correct the Receive Disable String when appliance is showing 404. Document was edited by Dean Flaming November 6th, 2018 to correct the steps not showing correctly due to format issues.
Check the following: DNS - Each Identity Manager appliance has a Forward (A) record and a Reverse (PTR) record. Reverse Proxy / VIP FQDN - Reverse Proxy or Virtual IP is Online and addressable... See more...
Check the following: DNS - Each Identity Manager appliance has a Forward (A) record and a Reverse (PTR) record. Reverse Proxy / VIP FQDN - Reverse Proxy or Virtual IP is Online and addressable both with a Forward (A) record and a Reverse (PTR) record. If you are using a load balancer/reverse proxy like F5 BIG-IP, be sure the virtual server health monitor reports the Pool as green.  See F5 BIG-IP docs on configuration​ inside blog post). Certificates - All certificates should have full chains - not just the child certs. Certificates which the Reverse Proxy uses for backend communication has complete certificate chain available to it for VMware Identity Manager appliances Subject Alternate Names for internal FQDNs if using specific certs (recommended). Identity Manager is using the Root CA which the Reverse Proxy or Load Balancer is using (not the full cert chain - just the root CA cert).  This means including any and all intermediate certs in the proper order. Ensure the certificate chains are in the proper order.  When pasting the OpenSSL PEM formatted certificate chain into VMware Identity Manager, the order is shown below.  This is assuming a child cert, two intermediate certs, and the CA certificate.  If there is only one intermediate, then obviously one cert would be removed.  If there are load balanced intermediate certs, then both may need to be applied (both will need to be loaded on an F5 BIG-IP Load Balancer for proper cert termination). -----BEGIN CERTIFICATE----- ...your child certificate goes here... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ...your first intermediate certificate goes here... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ...your second intermediate certificate goes here... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ...your root CA certificate... -----END CERTIFICATE----- For more on certificates, see the online VMware Identity Manager documentation. Firewalls - Routing 443 and other necessary ports (depending upon solution) between all subnets is open. Make sure each appliance can resolve and reach (ping) the FQDN IP. If you don't enable ICMP, then use `curl` commands to pull a web address via the console.  With the below, you should get a 'true' or 'false' depending on the status being returned.  The thing you are looking for is not the status - but that you actually get a response.  Whether it is true or false is irrelevant at this stage. curl 'https://<fqdn_of_another_appliance_in_the_cluster>/SAAS/API/1.0/REST/system/health/allOk' Test both the FQDNs of the appliances within the cluster as well as the cluster FQDN.  If you do not get a true or false on the above test, you'll need to narrow down why the appliance cannot resolve / connect to another appliance or the cluster FQDN. This partially goes to DNS again, but do an NSLOOKUP on both the names of the other appliances and the VIP(s) or cluster FQDN(s). This should be a good start.  If anything doesn't work, chase it down and figure out why. 
So from that screenshot, it looks like ElasticSearch is not working properly. Is this a single node or cluster? If it is a cluster, how many nodes (should be a minimum of 3 but can be more)... See more...
So from that screenshot, it looks like ElasticSearch is not working properly. Is this a single node or cluster? If it is a cluster, how many nodes (should be a minimum of 3 but can be more)? Assuming a cluster (and assuming 2.8.x), you may wish to proceed with steps around ElasticSearch to Troubleshooting Elasticsearch and RabbitMQ in the 2.8 Install and Config guide.  Your RabbitMQ messaging is working, so do NOT do anything to to RabbitMQ messaging! NOTE: Make a VM Snapshot before you change anything!! If it is just a single node, you might simply wipe the ElasticSearch indices and start fresh (I make no claims this will work, make it better, make it worse, etc. etc.).  Again.... make a VM Snapshot before you change anything!! Clear ElasticSearch Indices Procedure: Login to Identity Manager Console as root or SSH into Identity Manager and SU to root. Stop ElasticSearch:  sudo service elasticsearch stop Remove the indices  rm -rf /db/elasticsearch/horizon/nodes/0/indices/v3_2017-03-20 Or simply remove all the data in /indices/ and start fresh Restart ElasticSearch or reboot  sudo service elasticsearch start
Go into the Admin portal and under the CATALOG tab, select the SETTINGS tab then select the NEW END USER PORTAL UI section.  Check to see if the ENABLE NEW PORTAL UI button is active. If so, clic... See more...
Go into the Admin portal and under the CATALOG tab, select the SETTINGS tab then select the NEW END USER PORTAL UI section.  Check to see if the ENABLE NEW PORTAL UI button is active. If so, click it. This setting is stored in the DB.  When cloning, it can get reset. NOTE:  To get logged in as an appliance admin, browse to "https://<FQDN>/SAAS/login/0" and use your local admin account.  This will bypass all policies and authenticators.
This post will walk you through basics and the setup of a 3rd Party IdP within Identity Manager. For this blog post, we will be using two separate VMware Identity Manager tenants as this allows f... See more...
This post will walk you through basics and the setup of a 3rd Party IdP within Identity Manager. For this blog post, we will be using two separate VMware Identity Manager tenants as this allows for documentation of both sides for demonstration purposes. This post assumes either VMware Identity Manager 2.8.x on-premises tenant or newer, or a VMware Identity Manager SaaS tenant. Index: You will find the following topics within this post: The Basics 3rd Party IdP High Level Layout Configurations & Use Cases VMware Identity Manager as a 3rd Party Identity Provider to another Primary Identity Provider Another 3rd Party Identity Provider integrated with VMware Identity Manager Bidirectional Identity Provider Integrations Chaining More than 2 Identity Providers Logic Flows Setting up a 3rd Party IdP in VMware Identity Manager Resources The Basics: When setting up a 3rd party Identity Provider (IdP) with VMware Identity Manager, it is first important to understand the difference between Authentication and Authorization and which piece (i.e. “Who”) does what and when. The basic logic flow when VMware Identity Manager is part of this starts with VMware Identity Manager acting solely as a Service Provider (it is providing a service with the application catalog for users to choose applications for launch).  VMware Identity Manager can also act as a 3rd Party Identity Provider but in this initial authentication flow, it is just a simple service provider. The user browses to VMware Identity Provider. VMware Identity Manager contacts the Primary Identity Provider (the one doing the authentication) The Primary IdP requests the user enter their credentials. In Secure Addressable Markup Language (SAML) terms, this is the claim. The Primary IdP validates this claim against a security provider (in this case, Active Directory). The Primary IdP responds with an updated SAML assertion specific for the Service Provider allowing the user to utilize the Service Provider in question. Figure 1 - Common logic flow for two Identity Providers. For customers who are integrating with a 3rd party IdP such as Okta or Ping, it is important to first understand where the users will log in to (Which IdP will handle the Authentication) and where the applications are protected (Which IdP will hand the Authorization).   These are major points of understanding and must be comprehended first before proceeding as these can be either of the Identity Providers.  In the above (Figure 1) diagram - and in the following (Figure 2) diagram, we are showing VMware Identity Manager sitting in front of another Identity Provider, but these can be swapped as we will discuss in the next paragraphs. Typically with VMware Identity Manager and Workspace ONE, VMware recommends the VMware Identity Manager / Workspace ONE portal be where a user goes first to start their authentication.  This means, VMware Identity Manager is the Service Provider and the customer's other identity solution is the Identity Provider for VMware Identity Manager.  This allows the most flexibility overall for customers.  In this method, VMware Identity Manager is actually seen as the 3rd Party IdP to the IdP which is protecting the applications.  In this method, it does not mean VMware Identity Manager cannot protect apps, it just means the IdP which is currently protecting apps is considered the "Primary Identity Provider (IdP)".  The IdP where users login to is considered the 3rd Party IdP. Figure 2 - VMware Identity Manager acting as the 3rd Party Identity Provider to another Primary Identity Provider It should be clarified, this does not mean customers are forced into using VMware Identity Manager first in the user authentication process.  As stated previously, with VMware Identity Manager and its support of 3rd party IdPs, customers have the flexibility of configuring this in various ways.  This includes making VMware Identity Provider the Primary IdP (application protector) and other Identity Providers as 3rd party IdPs. Figure 3 - VMware Identity Manager acting as the Primary Identity Provider supporting another 3rd Party Identity Provider Configurations & Use Cases: Setting up a 3rd Party IdP in Identity Manager can be done in both unidirectional and bidirectional fashions.  Images of these can be seen above in Figure 2 and Figure 3. In a Unidirectional flow, authentication happens first on the IdP which processes user logins, then authorization of applications (app launches) is handled by the IdP which is protecting the applications. Using VMware Identity Manager as the User Authentication. NOTE: See Figure 2 above. This is a good scenario for when a customer already has a 3rd party IdP in place such as Ping or Okta and this 3rd Party IdP is protecting applications already. VMware Identity Manager would then be inserted into the flow to handle User Authentication to the 3rd party IdP. PROS: Less/No work to reconfigure applications. All applications protected by the 3rd Party may be presented in VMware Identity Manager. CONS: Users education will be necessary to redirect users to the new Identity Manager interface for login. Can easily integrate other VMware solutions for SSO such as Horizon, ThinApp, Horizon Air, AirWatch, etc. as well as Citrix solutions. Using VMware Identity Manager for Application Authorization.  NOTE: See Figure 3 above. This is an alternate scenario for when a customer already has a 3rd party IdP in place.  VMware Identity Manager would be inserted into the flow to handle application authorizations after the 3rd party IdP handled user authentication. PROS: Customers can keep their existing end user portal for authentication. It is possible to redirect to the VMware Identity Manager web portal for a better user experience. CONS: Cannot work with Workspace ONE unless 3rd Party IdP has an authentication exception rule to route all mobile requests to VMware Identity Manager. All SaaS Applications must be reconfigured to work with VMware Identity Manager. Does support support Horizon/Horizon Air/Citrix integrations. Figure 4 - VMware Identity Manager configured with another Identity Provider in a bidirectional IdP trust A Bidirectional flow is simply two Unidirectional flows where both IdPs handle User Authentication and App Authorization for the “respective" other IdP.  The general scenario is if a user authenticates to either IdP, they can be automatically authenticated to the other IdP and all applications. While many environments may need to operate utilizing this configuration, customers may wish to eventually migrate to a single identity management and single sign-on solution for simplicity sake. PROS: End Users are authenticated once and SSO is used to process further authentications to other IdPs. Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager). All applications protected by the 3rd Party may be presented in VMware Identity Manager. Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager. Can work with Workspace ONE for all applications protected by VMware Identity Manager. CONS: Two user portals creating additional administrative overhead. Complex setup and configuration. PSO recommended for environment mapping. User education required. May not support or not fully support Horizon/Horizon Air/Citrix integrations. May require complex authentication policies on one or both identity providers. Figure 5 - Chaining together multiple Identity Providers, including VMware Identity Manager Chaining 3 or more Identity Providers (IdPs) is also an option.  However, when approaching this option, one should determine whether it is more beneficial to chain in serial or in a star logic-flow form. Example: In a serial fashion (not shown on this slide), the 1st IdP authenticates users. A 2nd IdP protects applications and trusts the 1st IdP for authentication.  The 3rd IdP protects other applications and trusts the 2nd IdP for authentication. This option would be slightly less complex than the next option during initial setup but potentially more administrative overhead.  Additionally it is not as flexible as a star logic flow configuration. In a star logic-flow fashion, it would look something like this.  Each of the VMware Identity Manager tenants authenticates users. The backend Primary IdP tenant protects applications and trusts each of the VMware Identity Provider tenants as 3rd party IdPs for authentication.  The Primary IdP tenant protects other applications and trusts each of the VMware Identity Manager tenants for authentication. This option would be slightly more complex during initial setup but potentially much less administrative overhead assuming the same A.D. users and groups are synced across all IdPs.  While some environments may have to operate with this configuration, typically this configuration would be recommended mainly for migrations. PROS: End Users are authenticated once and SSO is used to process further authentications to other IdPs. Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager being the first authentication point). All applications protected by the 3rd Party may be presented in VMware Identity Manager tenants. Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager. Can work with Workspace ONE for all applications protected by VMware Identity Manager. CONS: Multiple user portals creating additional administrative overhead. Complex setup and configuration requiring a high level of planning up front. PSO recommended for environment mapping. User education required. May not support or not fully support Horizon/Horizon Air/Citrix integrations. May require complex authentication policies on one or both identity providers. Application management may be complex until all tenants brought together. Logic Flows: When incorporating a 3rd party Identity Provider, logic flows are altered based upon the end user story changes. In the case where VMware is linking to another Identity Provider which is protecting an application, VMware is seen as the “3rd Party Identity Provider” to the other “Primary Identity Provider” (it being the one protecting the applications).  When doing this in conjunction to adding in Single Sign-On support for Horizon 6/7/Air/Hosted, ThinApp, Mobile Apps, or other solutions such as Citrix remote hosted desktops and apps with XenApp 5/6/7 and XenDesktop 7, VMware Identity Manager becomes the new, front-facing login portal for all users in order to provide a seamless end-user experience across all devices, applications, and services. In the case where VMware Identity Manager is protecting applications such as Mobile apps but sits behind another Identity Provider, VMware Identity Manager is the Primary Identity Provider for any applications which it protects and the front-facing login portal which redirects to VMware Identity Manager is seen as the “3rd Party Identity Provider”. Setting up a 3rd Party IdP in VMware Identity Manager: In this procedure you will need two VMware Identity Manager tenants (either can be SaaS or On-Premises tenants). You will be setting up one VMware Identity Manager tenant as a 3rd Party Identity Provider within another VMware Identity Manager tenant which is acting as the Primary IdP. First let us get our descriptions clarified.  When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other, we need to ensure we know which one we are talking about in the following instructions. NOTE: Please reference Figure 2 and Figure 3 above when working through these procedures. 3rd Party Identity Provider - This is the “3rd Party" Identity Manager tenant which the user is browsing to in order to login and view the app catalog and launch the apps.  To note, when adding VMware Identity Manager to an existing IdP solution, this is how VMware recommends adding VMware Identity Manager to the solution since this allows incorporation with as little change as possible to the existing production environment while allowing incremental rollout to end users by having them authenticate to VMware Identity Manager to get all of their applications, desktops, mobile apps, and other services provided to them. Primary Identity Provider - This is the Identity Manager tenant (the IdP) which is providing authenticating and authorization to any of its application(s) and service(s) which it is protecting.  VMware supports VMware Identity Manager in this configuration as well with other 3rd party IdP solutions. Since we are using two Identity Manager tenants, there are two sides to this configuration.  One part is the work done on the Primary Identity Provider tenant and the other part is the work done on the 3rd Party Identity Provider tenant. The first part is configuring the 3rd Party Identity Provider tenant as a 3rd party IdP within the Primary Identity Provider Provider.  This is done from the Primary Identity Manager tenant which provides the application protection in order for it to know who to accept authentication requests from.  For example, Office 365 is protected by the Primary Identity Provider tenant…the 3rd Party Identity Provider tenant is where the user authenticates…and then the user clicks on an application called Office 365 which points the user to the Primary Identity Provider tenant and specifically to the Office 365 application for execution. Along with that redirection, the 3rd Party Identity Provider tenant provides a SAML Assertion which holds the appropriate claim to authenticate the user to the Primary Identity Provider and allow it to authorize the user to launch the protected application…in this case, Office 365. To get started, within the Primary Identity Provider Identity Manager tenant (i.e. The IdP which protects the applications), browse to the Admin Console from the Identity & Access Management > Manage > Identity Providers page and click on the Add Identity Provider button and select the Create Third Party IDP menu option. Fill in the necessary information in the New Identity Provider page. Identity Provider Name: A name for administrators to easily identify this new IdP. SAML Metadata: Provide the URL or XML of the 3rd Party IdP for trust.  When using another Identity Manager tenant as the 3rd party IdP, to obtain the SAML Metadata, login to the administrative console on the 3rd Party Identity Provider Identity Manager tenant and browse to Catalog > Settings > SAML Metadata and right-click the Identity Provider (IdP) metadata link and copy the link address.  The address will be as shown below, where <3RDIDPFQDN> is your 3rd Party Identity Provider Identity Manager tenant FQDN. https://<3RDIDPFQDN>/SAAS/API/1.0/GET/metadata/idp.xml Back in the Primary Identity Provider Identity Manager tenant (which protects the applications) where you are creating the new “3rd Party IdP”, paste or type the above URL into the SAML Metadata box and click the Process IdP Metadata button.  This will auto-populate most settings. NOTE: The four Name ID Values which show up after processing the IdP metadata are the attributes which will be used between the two IdPs for mapping user accounts.  Only one out of the four is needed (e.g. email) to match. NOTE: In this case, since we are using the same Active Directory between both Identity Manager tenants, we don't need to worry about account creation.  Had we decided to use different Active Directory environments (such as two different companies linking their Identity Manager tenants together) or two internally different directories (e.g. Active Directory users with one Identity Manager tenant and Open LDAP or Local Directory Identity Manager users with the other Identity Manager tenant), we would only need to ensure one of the attributes maps (and that no other attributes match a completely different account) with a user account on both sides (i.e. If using email address as the mapping attribute, the user account in Identity Manager tenant using active directory has the same email address defined in the general tab of the A.D. Users and Computers account properties as the email address within the Local Identity Manager user account). NOTE: If not using the same A.D. domain for both Identity Manager tenants and instead manually creating a test user, only the mapped attribute(s) defined need to have matching values between the two Identity Manager tenants.  Use the User and Groups tab in both Identity Manager tenants to compare your test account in each tenant to see if the mapped values match (for tenants using the same Active Directory domain, we know they will match so long as the test user account is synchronized to both Identity Manager tenants). NOTE: If some of the user attributes defined under the Name ID Value could potentially cross map to other user accounts, then remove them and stick with just the one or two attributes you know will be unique to each user (e.g. email or userPrincipalName). Name ID Policy is optional and not needed if doing Identity Manager to Identity Manager trusts. Just-In-Time User Provisioning is optional and would NOT be used if both IdPs are synchronized to the same Active Directory domain or if user account creation or synchronization is accomplished by some other fashion. If enabled, then an Identity Manager Directory name must be specified and it is recommended to provide a fully qualified domain (e.g. COMPANY.LOCAL, CUSTOMER.COM, etc.). Users: Select the user's directory/domain from the 3rd Party IdP which can authenticate to this Identity Manager tenant. Network: Select which network or network ranges the 3rd party IdP can be accessed from. Authentication Methods: Click the green “+” (plus) sign and add an Authentication Method. Give it a unique name and select urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport. Single Sign-Out Configuration: This is optional.  If enabled, provide a redirect URL for logout. Click the ADD button. The second part is to create an authentication policy with fallback authentication for automatic SSO of users coming from the 3rd Party Identity Provider Identity Manager tenant.  This will allow the VMware Identity Manager tenant acting as the Primary Identity Provider to authenticate to the 3rd Party Identity Provider. Within the Primary Identity Provider Identity Manager tenant (i.e. The one which protects the applications), this is done within the Admin Console from the Identity & Access Management > Manage > Policies page by clicking on the default_access_policy_set and editing each of the authentication methods to add in the new fallback authentication created in step 1.1.7 (NOTE: The unique name should now appear as an authentication method). When opening the default_access_policy_set, you will see multiple authentication methods (by default you will see two - Identity Manager Client App and Web Browser). Edit all Policy Rules and add a new “Fallback Method” by clicking on the green fallback Method button. NOTE: DO NOT ADD A SECONDARY AUTHENTICATION METHOD TO THE NEW FALLBACK METHOD! From the new dropdown menu, select the newly defined method from the above procedure. Click the OK button. After all (or at least the desired) Policy Rules have been modified, click the SAVE button on the bottom of the default_access_policy_set page. The Primary Identity Provider Identity Manager Manager tenant is now trusting the 3rd Party Identity Provider Identity Manager tenant and ready to authenticate and authorize users. The final part is to create a linked application from the 3rd Party Identity Provider Identity Manager tenant to the Primary Identity Provider Identity Manager tenant.  In this case, this is done on the 3rd Party Identity Provider Identity Manager tenant which is providing the initial authentication for user accounts (not the same tenant as the one used above in steps 3 and 4). NOTE: When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other Primary Identity Provider, we can link to one of the applications from the Primary Identity Manager tenant or we can link directly to the Primary Identity Provider tenant CONSOLE or Application Catalog, using that as the “application" which the Primary IdP is protecting (this is the app catalog console which a user would see when logging directly into the Primary IdP Identity Manager tenant). Within the Service Provider Identity Manager tenant - where users will login to (i.e. NOT the same as the IdP Identity Manager tenant mentioned in the previous two major steps), this is done within the Admin Console from the Catalog > Manage > Application Catalog page by clicking on the Add Application button and selecting “…create a new one” from the Web Application menu. When adding a new application in Identity Manager, a new window will appear requesting the application details. The only two details we need for this first window are a Name (the user will see this as well as any description added) and an Authentication Profile of SAML 2.0 POST Profile.  It is recommended to add an icon which makes appropriate sense for end users to easily distinguish this application from others as well as a description but these are not absolutely required. Here we will use the Identity Manager IdP tenant catalog as the “application”. For Name, type "3rd Party Catalog”. For Description, type “Application Catalog of IdP Identity Manager Tenant <FQDN>” where FQDN is the actual FQDN of the IdP Identity Manager tenant. If you have a custom image you wish to use, click the Choose File button and browse to the image file and upload it. Ensure Authentication Profile is set to SAML 2.0 POST profile. Click the NEXT button. In RelayState type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN. https://<IDPFQDN>/catalog-portal/ui NOTE:  You may choose to use any actual application protected by the Primary FQDN tenant.  In that case, the RelayState URL pasted here is the Launch URL of the application from the Primary Identity Provider. For finding the Launch URL for non-SaaS/web based resources (e.g. Horizon, etc.), see further down. Leave Proxy Count and Login Redirection URL blank. Leave all check boxes and other options in their default state. In the Auto-discovery (meta-data) URL, type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN.  This is the Service Provider XML information of the 3rd party IdP as we are now addressing it as a Service Provider to the application we are creating. https://<IDPFQDN>/SAAS/API/1.0/GET/metadata/sp.xml NOTE: You can obtain this link from the Catalog > Settings > SAML Metadata page within the IdP Identity Manager Tenant Administrator Console.  It is listed as Identity Provider (IdP) metadata within the SAML Metadata section of the page. Click the SAVE button to process the IdP Metadata information.  Doing so will automatically process the metadata information and move to the Entitlements tab. In Entitlements page, add in the Group or Individual entitlements. Assuming both Identity Manager tenants (both the SP and IdP) are synching the same set of users, simply entitle this app to ALL USERS.  Set entitlement to AUTOMATIC (vs. User-Activated).  Click SAVE on the Add Entitlements pop-up screen to get back to the main window. In the main window, ensure you click the DONE button above the Entitlements section. You should now be able to see the application in the catalog of the Service Provider Identity Manager Tenant as a regular user. Browse to the 3rd party Identity Provider (i.e. the VMware Identity Manager tenant which is in front of the Primary Identity Provider). This will be something like the following where <3RDIDPFQDN> is the FQDN of the first VMware Identity Manager tenant in Figure 2. https://<3RDIDPFQDN> Login as a standard user who was entitled in Step 5.A.10 above (assuming the built in All Users group was used to entitle users, then any user will see the app). This user should have access to and see the newly created application from the previous section. Launch the application. This user should see the launch of the above application kick over in the browser to the Primary Party IdP VMware Identity Manager tenant. Assuming everything is properly configured above, the user should see the web app catalog of the Primary VMware Identity Manager tenant (or the application it is protecting if specified as such in step 5.A.6) launch from the VMware Identity Manager tenant acting as the 3rd Party Identity Provider! Finding the Launch URL: SaaS/Web Apps Finding the Launch URL for SaaS/Web is fairly straight forward. Login as admin to your VMware Identity Manager tenant. Browse to Catalog (drop down arrow) > Web Apps and select the desired web app. Within the app details, you'll see the Launch URL shown. Click the COPY URL to copy the link. Non-SaaS/Web Apps (e.g. Horizon, Citrix, ThinApp, etc.) While it is fairly easy to find the Launch URL for SaaS/Web resources within the VMware Identity Manager admin console, doing so for non-web resources is a bit trickier as the full URL is not listed.  It is, however, still pretty easy to do. Login as admin to your VMware Identity Manager tenant. Browse to Catalog (drop down arrow) > Web Apps and select any web app. Within the app details, you'll see the Launch URL shown. Click the COPY URL to copy the link. Paste this link within a text editor. Browse to Catalog (drop down arrow) > Virtual Apps and select the desired virtual app. Select the resource's Details on the left side menu. Within the app details, highlight and copy the External ID (SID) value. Within the text editor, modify the pasted URL by replacing the GUID at the end of the Web App Launch URL with the GUID from the Horizon Resource External ID (SID). Resources: VMware Identity Manager Documentation - This is the latest online VMware Identity Manager documentation.  Please note that you need to select the proper VMware Identity Manager version!  You will also need to search the respective version documentation for the topic, "Configuring a Third-Party Identity Provider Instance to Authenticate Users". VMware Identity Manager Integration Documentation - This is all of the latest VMware Identity Manager integration docs published by VMware. VMware Workspace ONE integration with Third Party Identity Providers - This provides integration information between VMware Workspace ONE (VMware Identity Manager) and Third Party Identity Providers. Please feel free to send any feedback to respective content authors.
I took the liberty of testing this as another customer brought this to my attention.  It seems it's not specifically an issue with Flash or Firefox but rather a Java + UAC issue.  I'm making a fe... See more...
I took the liberty of testing this as another customer brought this to my attention.  It seems it's not specifically an issue with Flash or Firefox but rather a Java + UAC issue.  I'm making a few assumptions here as everything started working for me when I did the specific "Java 1.6 Tweaks" (also noted in the "How to ThinApp Newer Versions of Java" blog post just prior to step 4). Specifically, the added Java browser helper objects seem to be causing the UAC issues.  Not sure why it only appears after launching Flash first though. Anyways, I captured the above versions together in a single package on a clean XP SP3 system and after the java tweaks and Flash MMS.CFG settings, was able to get the entire thing working on XP, Win 7 32-bit, and Win 7 64-bit.  Even did the "Dirty, Washed, Clean, Production" tests as well and all worked.
As others have said, there are no specific guides.  There are other documents, discussion threads, and presentations discussing this, however. ThinApp Troubleshooting - http://blogs.vmware.com... See more...
As others have said, there are no specific guides.  There are other documents, discussion threads, and presentations discussing this, however. ThinApp Troubleshooting - http://blogs.vmware.com/thinapp/2009/05/app-troubleshooting.html ThinApp Troubleshooting-Repost - http://blogs.vmware.com/thinapp/2010/01/thinapp-troubleshooting-repost.html ThinApp Bootcamp - http://communities.vmware.com/community/vmtn/desktop/thinapp/bootcamp See the Performance Enhancing, Design Best Practices, and Implementation Best Practices sessions.
Slowness can be caused by any number of things inside the virtualized application or outside the virtualized application on the native Windows environment.  Without knowing more about what applic... See more...
Slowness can be caused by any number of things inside the virtualized application or outside the virtualized application on the native Windows environment.  Without knowing more about what application you have packaged, there are some things I can suggest checking. Probably easier than typing them all out here is if I point you to the ThinApp Bootcamp series videos.  Specifically I would suggest my ThinApp Performance Enhancing session as this video discusses these slowness issues (maybe not specifically the FILE|OPEN window but it does give some ideas on things to check).  Probably my first guess would be AV. NOTE:  You should be able to view them directly on YouTube or Vimeo as well.  Please let me know if you cannot access these sites and I'd be happy to send you the videos directly through some other file sharing means. Regarding the lock file icons, this specifically is a newer Windows feature.  The reason for the lock icon is to denote (roughly) "No access to (general) Users".  Special groups such as Administrators may have access. Reference:  What are the padlock icons on folders for? - answers.Microsoft.com While not recommended, you can remove the lock icons simply by changing the native folder permissions.
There is no way to open/edit a ThinApp created EXE (package). All edits must be done to the project files/registry prior to building the ThinApp package.
A ThinApp 4.x license should work on all versions of ThinApp 4.x. As an example, if you look in ThinApp Factory, you have the option of building a ThinApp project with any 4.x version from 4.0... See more...
A ThinApp 4.x license should work on all versions of ThinApp 4.x. As an example, if you look in ThinApp Factory, you have the option of building a ThinApp project with any 4.x version from 4.0.4 on (I believe). No license change is necessary.  This means you can do the same manually with a standalone copy of ThinApp on a clean Win NT 4 system and higher.
Just out of curiosity, are you using different protocols or the same protocol?  Example, are you using PCoIP to get to the first desktop and then PCoIP from that desktop to the second or are you ... See more...
Just out of curiosity, are you using different protocols or the same protocol?  Example, are you using PCoIP to get to the first desktop and then PCoIP from that desktop to the second or are you using RDP to the second desktop instead? Just curious what you've tested in this regards.
Try redirecting your ThinApp sandbox to somewhere outside the user persona/profile.  Try the user home drive or similar.  I've seen this work.
Just to clarify, ThinApp DOES support A.D. Security groups within ThinApp packages by use of the PermittedGroups setting (which goes under the Build Options in the Package.ini).  This setting can... See more...
Just to clarify, ThinApp DOES support A.D. Security groups within ThinApp packages by use of the PermittedGroups setting (which goes under the Build Options in the Package.ini).  This setting can be defined for the entire package under the BuildOprions section of the Package.ini file or for each Entry Point or both.  Additionally, ThinAp also supports A.D. Computer Security Groups via a PermittedCompuetrs setting (which goes under the Build Options in the Package.ini). When using THINREG.EXE ( http://blogs.vmware.com/thinapp/2010/04/simple-thinregexe-login-script.html ) or the ThinApp SDK ( http://blogs.vmware.com/thinapp/2012/03/configuring-the-thinapp-sdk-in-place-of-thinreg.html ) to register the packages, they are only assigned based upon the A.D. security groups defined in the packages (or nested security groups the user is a member of where the app is assigned to the parent group). See this video as an example. http://www.screencast.com/t/ZjYyNzEzMTY See the ThinAp online pubs for more details. http://bit.ly/ThinAppPubs
@MapleLeaf - In your case you need to do the following to the IE project: 1.  Set all desired processes to run natively, not letting them default to running within the virtual bubble.  This is... See more...
@MapleLeaf - In your case you need to do the following to the IE project: 1.  Set all desired processes to run natively, not letting them default to running within the virtual bubble.  This is done by use of the "ChildProcessEnvironmentDefault" and "ChildProcessEnvironmentExceptions" build option settings. 2.  Additionally, so external processes can see these files from the virtual IE app, you'll need to customize the folder isolation settings for the following folders. %Temp% - create this if it doesn't exist.  Set the isolation to MERGED in the ##ATTRIBUTES.INI file.  Delete all other contents. %Cache% (or IE Cache folder) - set to MERGED isolation and delete all contents except ##ATTRIBUTES.INI file. Probably need to do the same for %Profile% if exists or just delete it. Depending upon where else IE stores files for web apps, you may need to do the above for other folders.  You may also need to set VirtualizeExternalOutOfProcessCOM=0 as a build option. As for the licensing issue, once you get the processes launching externally, you won't have the licensing issue with Office. Then build, wipe your sandbox, and rest.
Check your active directory synchronization settings.  The defaults are 90 minutes I believe for standard info synch such as security group changes (high priority such as password changes or acco... See more...
Check your active directory synchronization settings.  The defaults are 90 minutes I believe for standard info synch such as security group changes (high priority such as password changes or accounts being disabled are done immediately). You can go into AD Sites and Services and force the synchronization. http://technet.microsoft.com/en-us/library/cc816926(v=ws.10).aspx Additionally, the workstation OS will have cached logon settings.  If you wish to test the app assignments via security group changes, you may wish to modify the below setting to 0. Computer Config \ Policies \ Windows Settings \ Security Settings \ Local Policies \ Security Options \ Interactive Logon Number of Previous Logons to Cache: 0 NOTE:  If you set the above on a laptop, this will disable the laptop's ability to logon when not connected to the domain!  Change the above setting at your own risk!  The same goes for Offline View desktops!
Per the ThinApp User Guide and ThinApp Blog articles, a Clean PC of your lowest common OS is recommended to start with.  However, it may not always be the case.  See the ThinApp Blog article, 'Wh... See more...
Per the ThinApp User Guide and ThinApp Blog articles, a Clean PC of your lowest common OS is recommended to start with.  However, it may not always be the case.  See the ThinApp Blog article, 'What do you mean by "Clean PC"' for a good description of what your capture and build VM should be. Hope this helps!
For #2, you'll likely want to use the IgnoreDDEMessages=1 Buil Option in the ThinApp project's PACKAGE.INI file.  See the ThinApp 4.6.2 Release Notes (http://www.vmware.com/support/thinapp4/doc/r... See more...
For #2, you'll likely want to use the IgnoreDDEMessages=1 Buil Option in the ThinApp project's PACKAGE.INI file.  See the ThinApp 4.6.2 Release Notes (http://www.vmware.com/support/thinapp4/doc/releasenotes_thinapp462.html) for more info on this setting.
Firefox versions 9 and 10 work fine for me as ThinApp packages. For updating a ThinApp package, I suggest reviewing the following: ThinApp Blogs: A Guide to Updating a ThinApp - http://blogs.... See more...
Firefox versions 9 and 10 work fine for me as ThinApp packages. For updating a ThinApp package, I suggest reviewing the following: ThinApp Blogs: A Guide to Updating a ThinApp - http://blogs.vmware.com/thinapp/2010/05/thinapp-updating.html ThinApp BootCamp Series - http://vmware.com/go/thinappbootcamp