@Dashrender said in PDQ Drops Inventory (Deploy) Agent:

@coliver said in PDQ Drops Inventory (Deploy) Agent:

@warren-stanley said in PDQ Drops Inventory (Deploy) Agent:

@coliver from memory it allowed endpoint status display, along with connection when outside the corporate network for running commands and application management.

It was part of the subscription and didn't require any other additional setup - so was nice in theory.

Ah. Salt and Ansible can do similar things but would require some backend work.

Salt has an agent, right?

Yes, and Ansible can be setup in a Pull configuration so it can act like it has an Agent as well.

@marcinozga said in Any Way to Automate Adding a New Computer to an AD Group?:

@flaxking said in Any Way to Automate Adding a New Computer to an AD Group?:

@marcinozga said in Any Way to Automate Adding a New Computer to an AD Group?:

Ansible can do that. https://docs.ansible.com/ansible/latest/modules/win_domain_group_membership_module.html#win-domain-group-membership-module
You can add new PCs to domain, and change their group membership, you just need to know computer names in advance.

Which is just a layer on top of Powershell. The Active Directory Powershell module is still required.

It's not required, or that module is included already in Windows 10 by default. Because I haven't had to install it on any machine I managed with Ansible.

"win_domain_group_membership requires the ActiveDirectory PS module to be installed"
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_domain_group_membership.ps1

They have it in the documentation as well "This must be run on a host that has the ActiveDirectory powershell module installed."
https://docs.ansible.com/ansible/latest/modules/win_domain_group_module.html

@jt1001001 Thanks. If you are running from PDQ deploy, you won't see anything. But, if you are doing it from PS/ISE or similar, that would be a great help.

I know this is an old question that I'm replying to, but I found this post while searching for an answer to a different Citrix problem and I would like to offer some information in case anybody is still having the problem.

Our Problem:
In our environment we noticed when upgrading from Receiver 4.9 CU5 to Citrix Workspace App 1912 CU1 that Citrix App shortcuts were not showing up on the desktop for users. We have the "Show apps on desktop" setting configured via group policy and we have the Mandatory keyword in a lot of our Citrix apps. This all worked fine with Receiver, but with Workspace App, whether it was an upgrade to Workspace App on an existing endpoint or a new installation on a new endpoint, the user's Citrix Apps would not enumerate on the desktop unless the user opened the app pick list or ran a WSA reset.

Solution That Worked for Us:
Add the following Reg strings:
x64 machines - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Dazzle
RefreshMs = 3600000
InitialRefreshMinMs = 1
InitialRefreshMaxMs = 1

x86 machines - HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Dazzle
RefreshMs = 3600000
InitialRefreshMinMs = 1
InitialRefreshMaxMs = 1

Enabling Prelaunch on Endpoints also seemed to help with this issue. See the below Citrix Article for more info:

https://support.citrix.com/article/CTX239186

Passthrough authentication is delayed on Workspace App for Windows 18.8.0.19031
Article | AuthenticationConfiguration | 2 found this helpful | Created: 29 Oct 2018 | Modified: 29 Oct 2018
Symptoms or Error
Pass-through authentication is delayed on Workspace App for Windows 18.8.0.19031 Once user logs on to desktop, Workspace App does not log in automatically. User has to right click on Workspace App icon in system tray and click on logon. Application shortcuts are to be placed on desktop - This is enforced by policy. As Workspace App does not log on, apps are also not enumerated on the desktop. If user closes Workspace App and reopens from Start menu, logon is instant.

Solution

Make sure the following registry keys are present:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Dazzle
RefreshMs = 3600000
InitialRefreshMinMs = 1
InitialRefreshMaxMs = 1

Use Receiver GPO to enable Prelaunch if it is required

Problem Cause
Prelaunch behavior has been re-designed in newer Receiver/Workspace App

@jaredbusch said in PDQ Deploy:

I quit using PDQ with any regularity when I found chocolatey.

Same, but I only used it at the last job, now I just use a chocolate ps script that does all of it.

@Dashrender said in Deploying Veeam Endpoint Backup on Windows with PDQ Deploy:

I'm not sure where else to mention this, but Chocolately would be another deployment method to consider.

Yes, no native package, though. So we need to make one for it. That would be my personally preferred method, of course.

They use different install locations. Each maintains its own space and database. They don't interact at all.

@IRJ said:

@ajstringham Yes

Got it. Everything nowadays is. Not surprising really.