sean_a

Quote

 Even if it was that maybe the OS could use a reboot where if it's more than 7 days (for example) you might prompt the user to restart?

A reboot would be a simpler method, for (obvious) reasons of restarting FileWave client and general macOS stuff.

Quote

You don't need to read the logs, you could instead query the server for that value if you like.  Just consider how often you would be doing this though.

valid point on the "how often" part.

Thank you everyone for your guidance!!

we are trying to reduce/eliminate the number of macOS devices that have last connection dates of x days or more.

one idea under investigation is to compare client-side last connection date with date. If difference is over x days, then implement some kind of client-side notification.

Still looking but not yet finding it: Is last successful connection saved somewhere on the macOS client (so it can be captured by a launch daemon/agent or query)?

that’s right - you said in slack you were on 14.8.0, so presumably ports are not a variable.

on-prem or cloud?

what FW version were you on prior to upgrade?

if on-prem, what troubleshooting steps have you done (i.e., restart server services, reboot server)?

Speaking only for myself, though I would think a sentiment shared by others, I greatly appreciate your exhaustive, detailed answer to my admittedly open-ended question to this topic.

I look forward to FileWave's developments with DDM.

Thanks again!!

So, in regards to Declarative Device Management (DDM), I sort of get it.

Sort of.

Apple talks theory (see link from WWDC 2021), but what are the nuts and bolts, as it relates to FileWave?

I am going down the list in https://fwkb.atlassian.net/wiki/spaces/KB/pages/4329431/FileWave+File+Locations, hoping that I do not have to manually go down each and every FileWave Admin Audit History log file.

When an admin creates an association, it shows up in FileWave Admin Audit History, something like this:

2022-10-18 15:57:25.020 [P:1887] <ip:::ffff:10.10.10.333> user:username - Request id: FWS_ASSOCIATION_BATCH_CREATE, name: 'create new associations', owner session key hash: real_long_hash, owner name: 'username', result: 0
    client id: 'client_id_number, name: 'computer_name', fileset group id: fileset_group_number, name: 'name_of_fileset', revision: '<default> Initial Revision', revision ID: 'revision_id_number', association id: real_long_association_number

But, the create association -- especially the user who created the association -- does not show in any server side log, unless I am totally missing it. 

Does it show up anywhere?

FYI, this process only blocks the Ventura app, so it only provides one layer of protection.

Unfortunately, it does nothing to prevent Apple from publishing Ventura as a delta upgrade, since that upgrade is not an app.

FWIIW, @paul.bunyan’s blocker fileset works on macOS Ventura (I tested it with Ventura beta, so had to rename the installer application, of course).
Paul’s description and fileset are found here in Slack's MacAdmin workspace (FileWave channel)
https://macadmins.slack.com/archives/C053TS2M7/p1569339021172900

 https://macadmins.slack.com/archives/C053TS2M7/p1622565957089800

if using paul’s fileset, the user will see this error message after download (see attached).

Of course, FileWave has KBs on blocking macOS installer applications as well.
https://kb.filewave.com/display/KB/macOS+-+Block+Apple+Install+macOS+Application

https://kb.filewave.com/display/KB/Fileset+to+block+Applications+on+macOS

The reason for this request is an acknowledged edge case. In this case, I deactivated an association (pkg fileset), with the unintended consequence of deleting the software from clients since there was also a pre-uninstall script in the fileset, so the pre-uninstall script ran as clients left the association. I corrected my mistake fairly quickly, though I wanted all my clients to see my correction as soon as possible, even if doing so would put potentially put some load on the server. In retrospect, I did not need to force an inventory to all clients, because it seems the clients picked up the correction soon enough as the number of "uninstalls" was relatively low.

(Nothing like a Monday when you accidentally start deleting VPN software from laptops.... muhahahaha....haha....sigh.)

Is there a way to get all clients to re-submit inventory?

Would restarting service on filewave server do that?

Excellent question.

Adding to this thread since I had to look it up...

You can find the FileWave Foundry at https://foundry.filewave.com and can log in with the same single-sign-on credentials you use on filewave.com.

More details on Foundry at https://fwkb.atlassian.net/wiki/spaces/KB/pages/4328555/FileWave+Foundry

Not that i use TeamViewer in our environment, but what exactly are you seeing? 

For example:

• What have you tried and what is occurring? 
• What documentation are you referring to and what steps are not working?
• "Not working" can mean so many things.