SteveWH Tracker

Re: Is there a log file on the Connection Broker showing who's logged onto the VDI's system externaly?

SteveWH — Tue, 02 Apr 2019 16:32:46 GMT

There are files on the servers you can review however they are meant for diagnostic purposes and not reporting. The verbosity is also configurable to log greater detail but will have a performance/storage impact if adjusted.

For Security servers: If you are on Server 2008+ the location is DriveLetter:ProgramData\VMware\VDM\logs . (https://kb.vmware.com/s/article/1027744)

For UAG: Collecting Logs from the Unified Access Gateway Appliance

As techguy129 pointed out this data is also recorded in the Events Database if you have it configured under Horizon Admin Event Configuration. (Configuring Event Reporting ). Additional information on connection related events that are logged: (Horizon Connection Server Events )

If it's an active session you will see them under Horizon Admin 'Monitoring -> Sessions' and there is a column for 'security gateway' that shows which broker they connected through.

If it's a historical session you can go to Horizon Admin 'Monitoring -> Events' (if configured) and search the most recent 2000 events. Anything beyond 2000 events you will need to query the database directly.

You can reference these community threads regarding querying the database directly:

VMWare Horizon View Events (User Login History) how to source from (sql) database

View DB SQL how to extract Client's IP address

BenFB also pointed out the ability to send events to a syslog server as well which may be easier if you have an existing solution that parses out the data instead of querying SQL directly.

Re: Issue authenticating users via Identity Manager when a DC in domain is unreachable

SteveWH — Wed, 30 Jan 2019 22:12:15 GMT

Appears vIDM does authentication based on DNS SRV entries for the domain. In order to set which DC is used for authentication we needed to update the krb5.conf file in-line with this KB article: VMware Knowledge Base . We have adjusted as described and will be taking a DC offline tomorrow to see if we are able to reproduce the issue after these changes were made.

Re: Issue authenticating users via Identity Manager when a DC in domain is unreachable

SteveWH — Tue, 29 Jan 2019 14:27:24 GMT

While I'm glad I'm not the only one experiencing the issue I'm sorry you are too. I parsed out every file in the support bundle and no files reference the hostname or IP of the DC that was offline. The connector logs do reference the DCs that are in the domain file under 'java.naming.provider.url' and those are the correct two based on AD Sites + Services. Not sure if I need to enable more verbosity somehow or if the logs fail to show which DC is really being contacted.

Re: Issue authenticating users via Identity Manager when a DC in domain is unreachable

SteveWH — Tue, 29 Jan 2019 14:03:43 GMT

Thank you for the suggestion! Unfortunately I'm not sure it will help - we don't have the vIDM appliance configured to use the DC that went down. Based on what I can tell in the configuration and debug logs it's using a DC that is online and reachable in a site unrelated to the DC that was offline. Not sure a load balancer would help this situation since it would still be sending traffic to these DCs that are online and capable of authenticating.

Issue authenticating users via Identity Manager when a DC in domain is unreachable

SteveWH — Tue, 29 Jan 2019 13:40:06 GMT

We are experiencing an issue where logon times take 10+ minutes (or possibly fail to authenticate) when a DC on the domain is offline. It's important to note the DC doesn't belong to the AD Site that the Identity Manager appliance is serviced by based on subnet mapping so we are unsure why having the DC go down is impacting authentication via the Identity Manager portal. We have two DCs that service the site and both are online and able to authenticate clients (all other domain workstations in the site are able to authenticate successfully and I can authenticate directly to each of the DCs manually using LDP.exe as a test). When I check 'domain_krb.properties' I see the two correct DCs for the site the appliance is serviced by and neither of these DCs are the ones that are offline. Even if one were offline it is my understanding the solution would simply use the other, the whole point of having multiple - for redundancy. I enabled debug logging, gathered a log bundle from when the issue occured, and uploaded to case 19057761301. Not sure if anyone else has experienced this issue before so reaching out to the community for suggestions. It's been a week since the case was opened and I still don't even have an initial log analysis so trying to find the answer elsewhere.

Re: VDI user is assigned a desktop logged in by another user

SteveWH — Tue, 27 Nov 2018 19:39:49 GMT

Everything everyone has stated should be investigated as they could be the root cause. Out of curiosity what does your environment look like? Are you using zero clients or are these windows clients made into kiosks with the Horizon Client auto connecting at boot? There is a bug with the Horizon client that causes the behavior you are experiencing but not sure if applicable here without knowing more information.

Re: Horizon F5 tcp Reset using UAG

SteveWH — Wed, 14 Nov 2018 16:36:11 GMT

To know for sure you would need to setup packet captures to see what is happening on the wire. If you can recreate the issue with a client you would ideally want to run a capture on the client, the F5, and the server but most likely just the F5 and remote server is needed. This will give you insight into why the RST packets are being sent from the F5 to the client causing the disconnection. If you can't reproduce the issue on-demand you would need to connect and run a rotating tcpdump on the F5 until the issue occurs. In the log excerpt you provided it shows the RST reason as 'Flow expired (sweeper)' The BIG-IP system will reap a connection from the connection table and send a TCP RST packet to the client when one of the following two conditions is met: 1) an idle timeout for the connection expired. This may be impacted by the Idle Timeout setting in the assigned TCP profile of the affected virtual server. 2) Memory usage on the BIG-IP system increased beyond the reaper high-water mark and triggered adaptive reaping.

K13223: Configuring the BIG-IP system to log TCP RST packets

https://support.f5.com/csp/article/K13223

K411: Overview of packet tracing with the tcpdump utility

https://support.f5.com/csp/article/K411

K13637: Capturing internal TMM information with tcpdump

https://support.f5.com/csp/article/K13637

The vendor you are working with can then analyze the capture files to see the communications leading up to the RST packet being sent. For example we had an issue where connections were intermittently being reset resulting in clients displaying a generic 'network error'. The client logs and server logs didn't show anything meaningful beyond the client being disconnected with a generic error. The F5 qkview's were clean and we were on latest versions and iRules in-line with the version of Horizon.

We connected to the F5 and checked the connections in real-time to monitor idle timers and session information (tmsh show sys connection) (tmsh show sys connection cs-client-addr x.x.x.x all-properties) but the timers weren't being reached and the system resources were in the green.

The traces ended up showing us TCP SYNS being sent but the server wasn't sending corresponding ACKs. Ultimately the F5 gave up and sent the RST to the client since the server wasn't responding. Not sure what you will see on your trace but you can feel free to post the results. For us the problem ended up being a mismatch between the default TIME_WAIT timer created in the TCP profile created in the Horizon iAPP vs. the default Windows Server TIME_WAIT timer.

Your issue sounds like it has a different root cause than us but I'll share the details of ours to show how the logs aren't always clear and the packet capture is needed.

By default the iAPP creates virtual server profiles that use SNAT automap with preserve source port. What this means is that the horizon client’s src port used to make the initial connection to the F5 is then used to make the second connection from the F5 to the connection server. For example:

CLIENT:50493 – F5:443 – F5:50493 – CONNECTIONSERVER1:443

The client uses a temporary ephemeral port to make the 443 connection to the F5. The F5 then uses that same ephemeral port to make the server side connection. This usually isn’t a problem but it could become a problem if you have many connections in a short period of time and the probability of a ports being re-used is increased.

The problem occurs when we increased the Horizon Global Setting for SSO timeout. We changed it from the default 15 minutes to the lowest available value of 1 minute. When we change the SSO setting to 1 minute it then has the client send a heartbeat every 20 seconds instead of every 5 minutes. This increases the amount of connections to the connection servers by 15.

This becomes a problem because clients are now communicating more frequently so the chance of re-using an ephemeral port in a short period of time is possible. This isn’t a problem for clients in a non-load balanced environment because they all have unique client IP addresses but in a load balanced environment the connection servers see all incoming requests from the same IPs (the IP of the F5 (depending on how many floating F5 IPs you have in the pool).

In accordance with RFC 793 windows has a bunch of TCP connection transition states. The one we are concerned about in this issue is the TIMEWAIT state. TIMEWAIT is supposed to be twice the maximum segment lifetime (2MSL). By default windows has this set to 4 minutes. So if you run ‘netstat’ you will see all connections in all the possible states: established, syn_sent, syn_recv, fin_wait1, fin_wait2, time_wait, close, close_wait, last_ack, listen, closing, unknown, etc.

When a connection is closed by the application the underlying TCP stack keeps the source IP address/source port combination in a TIME_WAIT state until the 2MSL timer is up. From the local end-point point of view the connection is closed but we’re still waiting before accepting a new connection in order to prevent delayed duplicate packets from the previous connection being accepted by a new connection. TCP blocks any second connections from the srcip/srcport pair until the TIME_WAIT state is finished. Any new connections coming in from that SRCIP/SRCPRT combo will be ignored and no ACKs will be sent for incoming SYNS.

This is a problem for load balancers like the F5 because it may re-use an ephemeral port if another client chooses to use it. The F5 also has a TIME_WAIT timer to prevent this from happening that should match the destination devices TIME_WAIT timer but it does not. By default the F5 timer is only 2 seconds whereas Windows is 4 minutes. This means a new srcip/srcport combo can be re-used after only 2 seconds on the F5 and it will try to proxy the connection to the server when that has the same srcip/srcport combo still blocked for another 4 minutes.

This is what was happening to us – we did a TCPDUMP on the F5 and we were sending SYNs to the connection server and not getting a response. It then tries retransmission 3 times and when it eventually fails it sends a RST back to the client telling it to disconnect thus the ‘Network Error’ our end users were receiving.

The windows server TIME_WAIT can be adjusted using the registry key: TcpTimedWaitDelay and accepts values from 30 seconds to 300 seconds with default being 240 (4 minutes).

I adjusted the connection servers to have 30 second TIME_WAIT and adjusted the F5 iAPP TCP profiles to be custom and use 30 seconds instead of 2 as well as disabling the TIME WAIT recycle option.

This issue would most likely not be seen by anyone in smaller networks because having different clients connecting using the same ephemeral port is unlikely. Depending on their configurations they may have many F5 floating IPs that connections go across which will also help mitigate the occurrence due to having more SRCIP/SRCPRT combinations. They may also change the source port settings to be changed sequentially instead of preserved so instead of the F5 using the same source port the client used it keeps its own table and just sequences it itself. All of these options can mask the underlying problem but the real fix is ensuring the timeout values are the same to limit port re-use during a time_wait period.

Re: User had two VM sessions.

SteveWH — Fri, 13 Apr 2018 18:06:31 GMT

Just checking in to see if jzumwalt 's recommendation helped or if you are still having issues.

Re: Force protocol

SteveWH — Fri, 13 Apr 2018 17:35:03 GMT

Under the Desktop Pool Settings tab in the 'Remote Display Protocol' section you have the ability to set the 'Default Display Protocol' to PCoIP. There should also be another option 'allow users to choose protocol' which controls whether users can override the default display protocol you selected. Simply change that value to No and it will force them to use the default protocol which you set to PCoIP. There is also a Group Policy setting you can set called 'AllowDirectRDP' which will prevent devices that are not running Horizon Client from connecting directly to Horizon Desktops through RDP: (Computer Configuration > Policies > Administrative Templates > Classic Administrative Templates > VMware Horizon Agent Configuration) and disable 'AllowDirectRDP'

Additional information:

Desktop Pool Settings for All Desktop Pool Types

Prevent Access to Horizon 7 Desktops Through RDP

Re: View DB SQL how to extract Client's IP address

SteveWH — Fri, 23 Mar 2018 21:02:46 GMT

If a client connects directly to the connection server then that client's IP address will show under 'ClientIPAddress'. If a client connects through a load balancer then one of the floating IPs will show under 'ClientIPAddress' and the actual client IP address will show under 'ForwardedClientIPAddress' as long as the load balancer is configured to insert the 'X-Forwarded-For' header. If 'X-Forwarded-For' isn't configured then the value will be NULL.

If 'X-Forwarded-For' is enabled then the connection server will see something similar to this:

2018-03-23T05:22:33.365-05:00 DEBUG (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) Request from /10.205.1.82: POST /broker/xml

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) Content-Type: application/x-www-form-urlencoded

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: host: [virtual.example.org]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: user-agent: [VMware-client]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: accept: [*/*]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: cookie: []

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: content-length: [179]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: content-type: [application/x-www-form-urlencoded]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: x-forwarded-for: [10.95.2.59]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) Forcing content type for XML API request to: text/xml

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: content-type: [text/xml]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: vdmconnectionsource: [VkRJQ09OTkkwMS53aHJzZC5uZXQ=]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: gateway-type: [SG-cohosted]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [r] (ajp:broker:Request5712720) Header: gateway-location: [Internal]

2018-03-23T05:22:33.365-05:00 DEBUG (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) Gateway headers sent to the broker:

2018-03-23T05:22:33.365-05:00 DEBUG (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) gateway-type = [SG-cohosted]

2018-03-23T05:22:33.365-05:00 DEBUG (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) gateway-location = [Internal]

2018-03-23T05:22:33.365-05:00 TRACE (0D88-1148) <Thread-35> [SimpleAJPService] (ajp:broker:Request5712720) Request task queued.

The POST to the connection server will be from an IP address belonging to the load balancer. In the data being posted, the load balancer will add the additional 'x-forwarded-for' header containing the source client ip address. In this example the load balancer is 10.205.1.82 and the client is 10.95.2.59.

You mentioned you are using an F5 in your environment. Are you using the F5 Horizon iApp template? Did you configure SSL bridging or SSL offloading? If you go to your http service profiles under 'Local Traffic' -> 'Profiles' is 'X-Forwarded-For' enabled?

Re: Horizon View doubles assignment of linked-Clone desktops 7.3.2

SteveWH — Thu, 15 Mar 2018 00:29:23 GMT

That is correct - option would only be available in floating not dedicated. Original poster only mentioned linked clones - I should have asked which type of user assignment was being used.

Re: Horizon View doubles assignment of linked-Clone desktops 7.3.2

SteveWH — Wed, 14 Mar 2018 15:42:20 GMT

In your Horizon desktop pool settings can you confirm 'Allow user to initiate separate sessions from different client devices' is set to 'No'. If this is set to 'Yes' then any additional connections from the same user will result in new available VMs being assigned. If this is set to 'No' then the user will be be connected to their existing session and the original client will be disconnected.

Re: View DB SQL how to extract Client's IP address

SteveWH — Sat, 24 Feb 2018 15:12:45 GMT

The client IP address is recorded in the Horizon Event database. You need to select records from the 'event' table that have 'EventType' of 'BROKER_USERLOGGEDIN'. You then inner join the 'event_data' table on 'EventID'.

Example:

select *

from event e

inner join event_data ed

on e.eventid = ed.eventid

where e.eventtype = 'BROKER_USERLOGGEDIN'

order by e.time desc

When you execute the query you will notice multiple rows are returned for each login event. Each row contains a different attribute related to the login: 'ForwardedClientIpAddress', 'UserSID', 'ClientIpAddress', 'BrokerSessionId', 'UserDisplayName', and 'TotalUsers'. If you want to transpose rows to columns so data is returned in one row per login event you will need to pivot.

Example:

select *

from (

select

e.time as "Time",

e.node as "Connection Server",

ed.name,

ed.strvalue

from event e

inner join event_data ed

on e.eventID = ed.eventID

where e.eventtype = 'BROKER_USERLOGGEDIN'

) t

PIVOT

(

MAX(strvalue)

FOR name in ("ClientIPaddress", "ForwardedClientIPaddress", "UserDisplayname")

) p

order by time desc

It's important to note that the 'event' and 'event_data' tables only contain recent data. If you want to include older data in your query you need to union the historical event data.

Example:

select *

from (

select

e.time as "Time",

e.node as "Connection Server",

ed.name,

ed.strvalue

from event e

inner join event_data ed

on e.eventID = ed.eventID

where e.eventtype = 'BROKER_USERLOGGEDIN'

) t

PIVOT

(

MAX(strvalue)

FOR name in ("ClientIPaddress", "ForwardedClientIPaddress", "UserDisplayname")

) p

union

select *

from (

select

eh.time as "Time",

eh.node as "Connection Server",

edh.name,

edh.strvalue

from event_historical eh

inner join event_data_historical edh

on eh.eventID = edh.eventID

where eh.eventtype = 'BROKER_USERLOGGEDIN'

) t

PIVOT

(

MAX(strvalue)

FOR name in ("ClientIPaddress", "ForwardedClientIPaddress", "UserDisplayname")

) p

order by time desc

Re: Manually modifying appstack

SteveWH — Fri, 10 Nov 2017 12:50:45 GMT

I did find a site http://appvolume.readthedocs.io/en/latest/ that appears to be from the App Volumes dev team.

It has information written by Principal Engineer Matt Conover and Staff Engineer Art Rothstein.

In the guide it clarifies that "SvDriver is a policy-driven driver file responsible for the virtualization of volume contents into the desktop OS. The policy file snapvol.cfg controls the files, directories, registry keys, and processes that are virtualized during application capture on each volume. The log svdriver.log tracks this activity."

This explains how snapvol.cfg is used for both appstack and writable volumes - it is the policy file that svdriver uses for all virtualized volumes used in App Volumes.

Another area discussed that may be helpful in determining what is being captured:

"The SvCapture service performs provisioning and editing functions during application capture, such as generating policy files and metadata. The SvCapture reports this information to the App Volumes Agent and App Volumes Manager. svcapture.log tracks this activity and is available only on the capture machine.

For information to increase the logging level to debug, see Increasing Logging Level for AppVolumes Manager (2101668)."

I haven't reviewed the svcapture log file to see what information is contained but it's nice to know it may provide a summary of what was captured so the person doing the appstack provisioning has better insight. I still believe mounting the vmdk is the best method to review the files/folders/registry keys and policies related to the appstack.

Re: Manually modifying appstack

SteveWH — Fri, 10 Nov 2017 11:46:57 GMT

I did see talks about snapvol.cfg during my research but it was always mentioned in regards to writable volumes and not appstacks.

Both

https://blogs.vmware.com/euc/2016/03/app-volumes-snapvol-cfg-writable-volume-customize-configure.html

and https://docs.vmware.com/en/VMware-App-Volumes/2.12.1/App-Volumes-User-Guide-212-1.pdf

mention snapvol.cfg for writable volumes and not appstacks.

To make it more confusing there was a KB article: https://kb.vmware.com/s/article/2146963 that talked about an appstack snapvol.cfg and a writable volume snapvol.cfg which hints to what you mentioned - that the snapvol.cfg does infact work for normal appstacks and not just writable volumes despite not being listed in the user guide or blog websites that describe snapvol.cfg .

I will take a look at snapvol.cfg as well to see how it works in our environment. Thank you for the additional info on the svdeleted keys as well as modifying the scripts to perform actions like licensing.

Re: Manually modifying appstack

SteveWH — Fri, 10 Nov 2017 10:55:39 GMT

This is all great information thank you guys! I wasn't sure I would hear from anyone so I didn't elaborate. I did preliminary research prior to asking this question on the community and found one site:

https://blogs.vmware.com/consulting/2015/08/cloning-appstacks-and-modifying-scripts.html .

It mentions the same steps of adding the vmdk to a VM that doesn't have app volumes installed. The problem is it didn't offer any additional information beyond that.

I followed the steps in the article and realized I needed to add a drive letter to access the 'CVApps' volume. As previously mentioned it appears the volume includes other items related to the operational aspects of app volumes and not just the captured data.

The two items I found during review that seems relavent were the SVROOT folder which appears to be the files/folders that were captured and snapvol.dat which appears to be the captured registry data in addition to metadata related to objects in SVROOT.

The snapvol.dat contains three hives - MACHINE, METADATA, and USER. It seems simple enough - MACHINE is HKEY_LOCAL_MACHINE, USER is HKEY_USERS, and METADATA is the metadata related to the SVROOT contents.

I am wondering how sensitive the app volumes solution is. If I remove a file/folder from SVROOT do I also remove the corresponding entry in the METADATA ? Did I miss anything else beyond SVROOT and snapvol.dat that needs to be taken into consideration to ensure the appstack will work or are these the only two areas in CVApps we care about? Is there any fling or 3rd party tool I am missing that helps with this process or is it really all manual?

I see responses mentioning a concern about the appstack being readonly and not being able to modify the contents unless you click 'update' and then mount the new non provisioned copy. It was suggested the workflow would be to update an existing appstack in the manager to create a copy and then to manually modify the copy, provision it, and then save it and assign to end users. My concern is this contradicts the reasoning for manually editing the appstack. I want to clean the image once it is already provisioning but unassigned. If I were to manually remove entries, and then go into provisioning it may just add the irrelevant data back when it attaches to the reference PC in order to finish the appstack update.

Can someone explain the deleteable flag? It was my understanding if the appstack isn't currently attached to a user I could manually edit it because it wouldn't be referenced. To that end I would remove assignments to the appstack to ensure noone had handles to it, and then manually modify, then rescan in manager and add assignments. Alternatively if it's one actively being used in production environment I would copy it finalize it, and then manually edit it before assigning it to users/groups. Where would the deletable flag come into play in all of this?

Manually modifying appstack

SteveWH — Thu, 09 Nov 2017 21:27:11 GMT

The Appstack capture process seems too simplified in that you hit start, make a change, hit finish, and it bundles everything up into a vmdk. I am use to tweaking packages and permissions as well as trimming the erroneous data that was captured and not needed. Is there a way to open an appstack and see the data it captured? For example mount the vmdk and see the registry keys, files/folders, etc. and then remove data that shouldn't have been captures as well as adjust ACLs etc?

I ask because our helpdesk is receiving reports of odd behavior with an application and I'm wondering if there is conflicting registry keys in an appstack being overlayed. Being able to see what's in the appstack would prove this is happening and being able to then delete the conflicting keys from the appstack would resolve the problem.

Re: Leveraging UEM to maintain a user activity log of logon, logoff, disconnect, reconnect, lock, unlock

SteveWH — Tue, 18 Apr 2017 21:16:53 GMT

During troubleshooting I did find that to be the problem. I was able to get this working by creating a custom app and setting flexengine to look for 'explorer.exe' and run a pre-import task of the logon VBS script. This is a workaround to sync vs. async environments. It appears the script would never finish (or would timeout) preventing/delaying explorer.exe from launching which is when the volatile registry keys and environmental variables are available. I can't change sync in this environment so I set the script to execute at explorer.exe launch instead of as a startup script and it is working. thank you for your help!

Re: Leveraging UEM to maintain a user activity log of logon, logoff, disconnect, reconnect, lock, unlock

SteveWH — Tue, 18 Apr 2017 16:42:13 GMT

I changed cscript to wscript and noticed the VBS script is erroring on the initial regread since the key doesn't exist. this then stops the script from continuing because of the error. I am looking into how to check the existence of the key by using regread and monitoring the err.level and looping until the condition is met. This may still be a timing issue and we just need to continue the loop on error

Re: Leveraging UEM to maintain a user activity log of logon, logoff, disconnect, reconnect, lock, unlock

SteveWH — Tue, 18 Apr 2017 15:56:24 GMT

I added a 'whoami' to the routine and saved it to an output file and confirmed it is running as the user and not another context. I can't explain why the script isn't getting the values at logon but it can if you manually run the script after you are logged in.