KACE generally works best when installed as part of the initial setup process. If it’s included in the base image and that base image is rolled out to x number of devices, you know that the KACE agent will eventually check-in with your appliance. Then you’ll have a complete inventory of workstations.

Installed after-the-fact is when it gets a bit trickier. The preferred method is to have a GPO install it for you. This works fairly well if your users are 1) always connected to the network and 2) reboot from time to time and 3) the computers are in the correct OU (or the GPO is applied to the correct OU…). But this isn’t always the case – and even still there are instances in which the stars just don’t all align.

Then there is Covid/Remote work. Computer GPO and startup-based-User-GPOs just don’t work well with the current on-prem Domain Controllers and remote workforce. Ok, enough about this, let’s get onto how!

Enter PSExec, the tried and true remote management tool. This assumes you have administrative permissions to access the remote system AND that the remote system is somehow connected to your network (via VPN).

Remotely Connect to workstation
psexec \\computername powershell.exe
mkdir c:\kace
Copy KACE Agent to the remote workstation
cp \\yourkaceservername\client\agent_provisioning\windows_platform\ampagent-9.1.204-x86.msi c:\kace\
Run the MSI quietly
cd c:\kace
msiexec.exe /i ampagent-9.1.204-x86.msi host=fqdn.of.kace.server.tld nohooks=1 /qn
exit

If the computer is NOT running a recent version of powershell – looking at you Windows 7 – you’ll have to replace powershell.exe with cmd.exe. And since cmd.exe doesn’t support UNC paths you’ll have to use net use to mount the drives as a letter and then copy that way. Or just start > run > \\computername\c$, and manually copy to the c:\kace directory.

Another way is via the Windows Admin Center (https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/deploy/install), Add the computer with required credentials, then launch PowerShell on the left-side panel.

I also found a few workstations that had a fully configured KACE agent installed but just refused to collect and send inventory information. In that case I ran a manual check:

c:\program files (x86)\quest\kace\runkbot 1 0
c:\program files (x86)\quest\kace\runkbot 4 0

Like all good companies, we have dynamic distribution groups / lists that are based on the location of the user. Example, a user has the Office location of “Australia”, the dynamic list has the filter of:

((((((Office -eq 'Australia') -and (RecipientType -eq 'UserMailbox'))) -or (((CustomAttribute2 -like 'IncludeAllAUSLists') -and (-not(CustomAttribute1 -like 'excludefromdynamic')))))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')))

The user was added and then the office location was of Australia was added (after troubleshooting below). He complained he did not receive an email that was sent to this distribution list, so I had to verify he was a member.

Connect to your Office 365 online powershell (I have it previously documented if you don’t remember).

$GROUP = Get-DynamicDistributionGroup "All-Australia-Employees"
Get-Recipient -RecipientPreviewFilter $FTE.RecipientFilter -OrganizationalUnit $FTE.RecipientContainer

Had a user with full modify permissions to some directories on a file server. They managed to completely fubar up the permissions when trying to 1) lock it down to just them and 2) disallow other users. You can see where this is going.

The backup user and local administrator no longer had access. I attempted to take ownership using the GUI, but it would just fail saying I don’t have permissions. I even “ran as administrator” to no avail.

Command line to the rescue!

• Open Command Prompt as an Administrator
• takeown /f “directory\subdir\moredir\*.*” /r /d y

Needed to connect to O365 when my account has MFA enabled.

New computer, so here’s the full setup.

Using Internet Explorer or Edge, open your ECP/EAC (Admin of Exchange) portal page on your O365 account.
Click on Hybrid
Click on Configure
This installs a clickonce app for the Exchange Online powershell module.

Open PowerShell as an Administrator
winrm quickconfig
Enable per the wizard
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'

Now connect to your O365 system
Open PowerShell (the exchange-based one from the first steps)

Connect-EXOPSSession -UserPrincipalName yourusername@yourdomain.tld
If prompted, sign in

Windows 10 Pro 1809/1903/1909, Pro N 1909 have all experienced this issue in my tenure. I’m sure it’s more than that.

Basically when I have a maximized application on my primary screen, the top of the screen is blank (black bar). This has happened with Chrome, Slack, and Adobe so far. I should point out that this is both through a docking station as well as direct monitor connections; in any case I have 2 total displays active.

I’m not sure of a permanent fix, but the temporary ones include:

1. Moving the application to the secondary monitor
2. Un maximizing the application
3. Pressing Shift + Ctrl + WIN + B – this resets the video driver
4. Reboot

The reset of the video driver is not very impactful and definitely fixes my issue, so I usually try that one first.