I recently had to upgrade a Horizon infrastructure with around 180 pools and different masters, as you can imagine, that could be exhausting first to check which master is in use and what’s the current snapshot as well, so after searching a little bit on the Net, I’ve able to find what I need :
Continue reading…Tagged: Horizon
ADFS with VMware Unified Access Gateway (UAG)
This article talks about configuration of ADFS with VMware Unified Access Gateway without the use of Workspace One Access.
There’re two use cases here to configure ADFS with Unified Access Gateway
- Use Case #1: ADFS as MFA, so users first authenticate using ADFS, and then authenticate using standard credential to get the list of available resources (desktop or apps)
- Use Case #2: ADFS for single authentication method, so users will authenticate once with ADFS and then will connect to VDI VMs or published apps without the need to enter any other credentials. This use case of course required VMware TrueSSO to works
Initial configuration is the same for both and to make it short here the different steps required:
- Change Expiration Period for Service Provider Metadata
- Deploy UAG
- Configure Edge Service and specify a Connection Server fqdn (not the load-balancer)
- Check connection is working
- Connect to <federation fqdn> and save the FederationMetadata.xml file
- Import FederationMetadata.xml in UAG (Upload Identity Provider Metadata)
- Configure UAG for SAML or SAML and Passthrough auth methods
- Specify Identity Provider
- Download SAML Service Provided .xml file
- Configure ADFS
- Add a new Relying Party Trusts
- Specify UAG SP .xml file as source
- Configure Claim Issuance Policy
- Connect to UAG as “client”
- Auth using ADFS
- Auth using AD credential
Now if we want to go further and implement ADFS with TrueSSO:
- Generate SAML IdP Settings
- Import signed cert or use Generated one
- Copy Content of Download IDP Settings
- Configure Horizon Connect Server for SAML auth with UAG and ADFS
- Connect to admin console of Horizon Connection Server
- Add SAML Authenticator for UAG
- Mode Static
- Past Content of UAG Download IDP Settings
- Change EntityId if required
- Add SAML Authenticator for ADFS
- Mode Static
- Past Content of FederationMetadata.xml
- Enable TrueSSO for UAG and ADFS
- Using vdmUtil, enable both authenticator
- Check True SSO connection
- Connect to UAG as Client
- Once authenticated to ADFS, the list of available resource appears, and you can login without any other cred
That said, let see with some nice pictures how we do that :
Continue reading…AppVolumes 2103 (4.4) Tools – Off line packaging for both AppVolumes On-Prem and on Azure
One of the great update from AppVolumes 2103 (aka 4.4) is now you can install only App Volumes Tools and package applications offline from a simple VM on VMware Workstation for example and produce the same package for App Volumes on Prem (.vmdk file) and for App Volumes on Azure (.vhd files). So exactly the same package for both environment.
So let me describe how I created my “Capture and Build” VM, how to capture and import your applications….
Continue reading…Adding Static Route to WS1 Access
I had a request from Spanish colleagues about adding static routes to Workspace One Access (in their case it was because of database in a different network).
I first had a look on our internal channel on Slack and find a first way to do it … but with Identity Manager version 3.3. However, when I try to test it in my Home Lab using my on-premise WS1 Access 20.10 it was totally different. vIDM 3.3 is based on Suse Linux when WS1 Access 20.10 is based on Photon 3. After some exchange by mail with my colleagues, they sent me the procedure they used for their deployment… different for the first two !!!
Yes they deployed Workspace One Access 20.01…
Basically both method work with vIDM 3.3 and Workspace One v20.01 as both are running Suse Linux
Method 1 : for Identity Manager 3.3 and WS1 Access 20.01: (thanks to Mahmood Ramzan for this one)
First edit “routes” files in /etc/sysconfig/network
vi /etc/sysconfig/network/routes
Then add your route in this form : <net_range>/<mask> <gateway> <interface>
10.1.2.0/24 192.168.12.254 eth0
Then restart your network and confirm the route is persistent:
# /etc/init.d/network restart
# ip route list
Method 2 : for Identity Manager 3.3 and WS1 Access 20.01: (thanks to Javier Perez for this one) :
After connecting to WS1 using sshuser and sudo as root (or direct login as root), create the ifroute-eth0 file
# vim /etc/sysconfig/network/ifroute-eth0
Add your route (same format as for vIDM 3.3)
and set permission on this file:
# chmod 644 /etc/sysconfig/network/ifroute-eth0
Restart your network as explained above.
Method for Workspace One Access 20.10 and upward :
Starting with Workspace One Access 20.10, appliance are based on Photon 3.0. So adding a file call route-eth0 in /etc/sysconfig/network-scripts make it works by running /etc/sysconfig/network-scripts/ifup-routes but it doesn’t works when booting the appliance.
To add static routes to Photon appliance you need to follow this procedure :
So once logged as root edit this file : /usr/local/horizon/scripts/networkwizard.hzn
# vi /usr/local/horizon/scripts/networkwizard.hzn
Find the section “function save_sysconfig_properties” around line 800 (803 to be precise)
Alter the file to set the routes by adding the following lines in green :
function save_sysconfig_properties() {
if [ $ETHO_DEVICE_RESTORED -eq 0 ]; then
# any DHCP
local DHCP=no
if [ "$SYSCONF_IPV4_IP0" = "DHCP" -a "${SYSCONF_IPV6_IP[0]}" = "DHCP" ]; then
DHCP="yes"
elif [ "$SYSCONF_IPV4_IP0" = "DHCP" ]; then
DHCP="ipv4"
elif [ "${SYSCONF_IPV6_IP[0]}" = "DHCP" ]; then
DHCP="ipv6"
fi
echo save $ETH0_CONF
echo -n > $ETH0_CONF
echo "[Match]" >> $ETH0_CONF
echo "Name=eth0" >> $ETH0_CONF
echo "" >> $ETH0_CONF
echo "[Network]" >> $ETH0_CONF
echo "DHCP=$DHCP" >> $ETH0_CONF
if [ -n "$SYSCONF_IPV4_IP0" -a "$SYSCONF_IPV4_IP0" != "DHCP" ]; then
echo "Address=$SYSCONF_IPV4_IP0/`mask2cdr $SYSCONF_IPV4_NETMASK`" >> $ETH0_CONF
echo "Gateway=$SYSCONF_IPV4_GATEWAY" >> $ETH0_CONF
echo "DNS=$SYSCONF_NET_DNS" >> $ETH0_CONF
echo "LinkLocalAddressing=no" >> $ETH0_CONF
echo "IPv6AcceptRA=no" >> $ETH0_CONF
echo "[Route]" >> $ETH0_CONF
echo "Destination=10.0.0.0/24" >> $ETH0_CONF
echo "Gateway=192.168.0.250" >> $ETH0_CONF
echo "GatewayOnlink=true" >> $ETH0_CONF
fi
if [ -n "${SYSCONF_IPV6_IP[0]}" -a "${SYSCONF_IPV6_IP[0]}" != "DHCP" ]; then
local ndx=0
while true
do
local tmpip=${SYSCONF_IPV6_IP[$ndx]}
local tmppfx=${SYSCONF_IPV6_PFX[$ndx]}
if [ -z "$tmpip" ]; then
break
fi
echo "Address$ndx='$tmpip/$tmppfx'" >> $ETH0_CONF
ndx=$(($ndx + 1))
done
fi
fi
}
Reboot the appliance to ensure it works fine
App Volumes, load balancer health check
I recently had an issue with one of my App Volumes server: even if my server was down in an App Volumes point of view (connection lost the database), my Kemp load balancer see it up and running because: the web interface was up and favicon.ico was also available.
The template for App Volumes (part of Horizon 7 Template) is, in my opinion not complete and it missed the right way to configure health check
So the right way to configure load balancer ‘s health check is the following :
For Kemp :
VMware Horizon on Windows Server Core 2019
I recently have a customer requesting to install VMware Horizon on a Windows 2019 Core server. Most of customers prefer to have the “Desktop Experience” but for security reason some other prefer to limit to shell only interface.
Before installing VMware Horizon, ensure that all updates are applied to Windows 2019 Core (I had some strange behavior before doing that, like impossible to have the Flex Admin console or get “Login failed” on the new HTML 5 consoles)
The first main concern is getting signed certificate ready so Horizon will use it instead of its self signed certificate.
After copying the certificate in a local folder :
1 ) From the Administrator command prompt, type “powershell” to execute PowerShell command
Composer Firewall Port
Ok by default Composer must be in the same domain or at list have Trust Relationship with domains where Linked Clone will be deployed….
But with Composer you can also deploy on other domains, the caveat however is that you can’t browse the OU on Horizon Admin console so you need to Copy/Past or write the full path for the correct OU.
That said, if you look at the firewall port required by Composer, unless 18433 between Horizon Connection Server (brokers) and Composer plus 1433 to join the Ms SQL Server, nothing is really explained and a doubt can exist about which port is required (and also who create account in the domain). So here the answer 🙂 :
First I confirm, Composer server is responsible to reach the AD domains and create Computer accounts. So the required port are :
Source Destination Ports Service
Composer AD Controllers 88/TCP Kerberos
Composer AD Controllers 135/TCP RPC
Composer AD Controllers 389/TCP LDAP
Internal View Composer error – another reason..
Ok, I know that View Composer is depreciated but sometime we don’t have other choice to use it, eg. when you need to deploy VMs is a more cost effective way than Full Clone on domain with no Trust Relationship with the one on which the brokers is joined to.
So I have a customer who have 3 domains with trust relationship:
- dom-adm for all admin account
- dom-res for all computers account (composer and brokers are on this domain)
- dom-usr for all users accounts
We created a service account in dom-adm for Composer and added it to “Administrator” local group in Composer server.
When I tried to add Composer server on Horizon admin console, it failed with the “Internal View Composer error. Contact your administrator.” message and absolutely nothing into the log, both on Composer and Horizon logs (sic.)
I first suspected an issue with the certificate but even after putting a signed certificate the issue was the same.
Finally I created a service account for Composer in the dom-res domain and used it to add Composer on my vCenter… and it worked !!
Recent Comments