Josh Levitsky

We are in the midst of publishing FileWave 14.9.3 and then 14.10.2 in order to include the latest Apache update. 14.9.3 will come first and is started with QA. Once that releases, we will publish 14.10.2 following it.

For sure we will think of a place to make it easy and I'll check that link out.

FileWave 14.10.0 We're going to start with the first customers soon on 14.10.0. I have the downloads that have cleared QA and so if you've reached out to me or you were previously on the list you should look for an email from me at the latest tomorrow. I'm trying to get everything published and ready. Below are 3 KB articles related to the release for all to see. If you are Hosted or On-Premise and would like to be in early adopters please do let me know. Some people like it because the new release has security updates and some people like it for the bug fixes. In either case feel free to discuss here. A KB article was published: How to Force a Reboot of macOS or Windows Devices after Installing a Fileset in FileWave v14.10+ https://fwkb.atlassian.net/wiki/spaces/KB/pages/132579329 A KB article was published: Customizing iOS Device Wallpaper with FileWave v14.10+ https://fwkb.atlassian.net/wiki/spaces/KB/pages/131924011 A KB article was published: Version 14.10.x New Features, Updates, and Enhancements (Feb 2023) https://fwkb.atlassian.net/wiki/spaces/KB/pages/129531905 https://custom.filewave.com/ has been updated to build 14.10.0 clients for macOS and Windows. Be mindful that you can select 14.9.2 on that page if you need to build an older client. Emails have gone out to Early Adopters both Hosted and OnPremise just now. Hosted will get upgraded on Tuesday Feb 21st unless a ticket is opened asking not to be, but this new version should be a good improvement including some memory leaks that were addressed in the Windows Client. If you have Windows systems you'll want this version almost certainly. We had some support cases and chased down memory leaks until we can find no more and we don't see the client leaking. In preperation for 14.10.0 see the 3 new ports listed here: https://fwkb.atlassian.net/wiki/spaces/KB/pages/4329171/Default+TCP+and+UDP+Port+Usage

So I ran /usr/local/sbin/fwsu and then checked /private/var/log/fwsu.log and saw that the offline catalog had updated. The Feb patches are not in Central because Microsoft must not have them in the offline catalog yet. So the solution would be to use FileWave Anywhere (Web) because of this. I raised that this is a concern about how the offline catalog is updated by Microsoft.

I think I see if you are looking in FileWave Central (Admin) and you don't see them can you look in Anywhere (Web) ? I picked one that was easy to pick out from the Feb 2023 patches. I've also asked internally why I only can pick to deploy this in Anywhere and don't see it in Central. If Anywhere works for you to assign then great. If you have a minute to open a support ticket that would let us work with you to see why Central doesn't show it, but I am going to try to work with support with my lab that is in this state.

Hi @FWCS Josh J I think I reproduced this. I added my iOS group to the screen and picked "Deploy to Group" after picking a rollout plan though I think the same happens no matter if I have a rollout plan or not. The device does not show Assigned. If I select the device (or devices) with the checkboxes, then it does assign and in FileWave Central (Native) I see the Association appear. You should likely open a ticket to see if support is aware of this and so you can be notified about any workaround or when it's addressed. I did reproduce this behavior on 14.10.0 beta just now but I don't have the latest build so I don't know if it's addressed in the build we will be releasing in the next week.

Hi @ttl there's not a central place published but you can post links here and in https://discord.gg/filewave so at least in either place searching either system should help someone find it. (If you don't do Discord then just here on the Forums is super and sometimes I copy things to Discord) Building up a public published place might be a good thing. We could leverage the Knowledge Base perhaps and have an article that links to GitHub repos and such.

You could use the one requirement script and where it checks for the one profile just use an OR condition in the script to say profile A or profile B if present is ok. If you wanted both then AND can do it. That's how I'd approach it. 2 scripts can also work I imagine but I've just not done that though I can't see why it wouldn't work if you are trying to say BOTH should be there because each script would have an exit code allowing things to run or not run. Single script would give you the ability to say this OR that.

It was found ( https://discord.com/channels/1018872427201175552/1070389183530664076 ) that the Port Tester for Windows may not run on some builds of Windows 10. In that discussion I mention the ports and what the tester does. This has been reported to development and a refresh of the Port Tester was planned for 14.10.0 anyway so we'll go through testing the new version on various Win 10 and Win 11. It did work on a current Win 11 system for me. The macOS Port Tester is already updated to line up with FW 14.9.2 ports and appears to work on multiple macOS releases including Ventura. So as not to send folks to have to look on Discord here are some key points: Port List that the tool checks on 14.9.2: • Server: 443, 20015, 20016, 20017, 20019, 20022, 20023, 20024, 20441, 20443, 20445, 20446 • Booster: 20013, 20014, 20018, 20025, 20026 • IVS: 67, 69, 80, 111, 4011, 2049, 20015, 20016, 20017, 20022, 20443, 20444, 20445 Windows 11 appears to run the tool. Windows 10 may have some releases that don't let it launch. You may get an error or a note about it not being supported on Win 10. Workaround: Running the macOS Port Tester if you have a Mac or... You can also cheat since we use TCP connections and if you install a telnet client on your machine and you telnet to each port if there is a connection made it's open. Not ideal but just mentioning that the port checking part of the tool basically does just that and then it also checks if the SSL cert on https://yourserver.com/ is valid. We'll get this worked out though.

I'll mention to support. If it's a browser issue you can try clearing your cache or emailing help@filewave.com as a backup.

As you may be aware, Apache recently released version 2.4.55 to address three vulnerabilities (https://httpd.apache.org/security/vulnerabilities_24.html). Our development team has reviewed all three (CVE-2006-20001/CVE-2022-36760/CVE-2022-37436) and found that FileWave is not vulnerable to any of them. Two of the modules are not used and the third module exploit is not relevant for our implementation. We plan to incorporate Apache version 2.4.55 or later in the next possible release, however, due to FileWave 14.10.0 currently going through QA, we have determined that it is not necessary to derail its release for a vulnerability that cannot be executed. If Apache releases further information about this or any additional vulnerabilities, we will continue to evaluate our position.

It appears that the latest Chromebook extension may display a "Retrieving Geolocation" tab when it's doing its inventory update and reporting location. Support is investigating this with a could of customers, but this seems to be something that you could see, and when I hear that this is resolved, I'll post an update. You can feel free also to file a support ticket if you want to know more directly from support.

Just not working via FileWave? Is the client on 14.8.0 or newer? I ask because scripts didn’t work on Win11 before 14.8.0 or FileWave. Otherwise share what the script is doing and maybe something will jump out as wrong.

I think you are right that the importer doesn't handle it but the script does. The importer needs an overhaul no matter what because of Deployments becoming the thing in the future. In 14.10.0 I believe you'll see more detail about Deployments in FileWave Central (Native) and over time Deployments takes over for Associations so something has to happen with the importer to move over to using APIs for making the Payload and Deployment, but I'm not sure of the timeline for that to happen. I doubt the importer would get enhancements for the current Associations / Filesets that exist today.

I'm hoping someone adds to this but time permitting I'll try to add something. If someone doesn't offer a PKG recipe for the thing you want to package, then the below does help with learning AutoPkg. It can get complex but below is also a tool that is meant to make things more simple. So long as you end up with a PKG you could add that to FileWave easily: https://www.youtube.com/watch?v=Pmm__UGbctg - MacTech about using AutoPkg https://www.youtube.com/watch?v=BI10WWrgG2A - MacAdmins conf on AutoPkg Level Up https://www.youtube.com/watch?v=5VKDzY8bBxI - MacAdmins using Recipe Robot to automate making a recipe https://cpb-us-e1.wpmucdn.com/sites.psu.edu/dist/4/24696/files/2016/06/psumac2016-81-Writing-better-AutoPkg-recipes-with-Recipe-Robot.pdf - Recipe Robot PDF of the video We also have a #autopkg channel on our Discord server where I shared a script and presentation that lets you automatically push new software versions from AutoPkgr to FileWave as a fileset. If you've not seen Discord, it's https://discord.gg/filewave and maybe if you are already good on AutoPkgr and have a recipe and it's more about automating it going into FileWave then maybe that script in Discord would give what you need. I'll attach it here so you wouldn't necessarily need to go over there. It's a PDF, video and script. autopkg_fw_demo.mp4 Using AutoPKG to support 3rd party apps - Mac.pdf autopkg_fw_import.sh

Hi @Marjorie Kagoo I posted something for macOS that I'll link to below. This is something that might need little adjustments for your org but @Emma Ainsworth could help you on your calls with her and of course I could offer advice to Emma if she needed to know something because I created this from research on this topic and some of the ideas came from something I found that existed for another MDM.

It seems to be a side effect to the thing we discussed to block private browsing. I thought it might be related and then found I still had the Fileset from that thread we had and confirmed it does block clearing the cache. Probably Apple looks at it like if you want to prevent them from hiding where they are going by blocking private browsing then blocking cache clearing would be desired too, but they don't have a way to allow you to only do one of those two if you wanted.

I've seen Nudge used by folks from all the main MDM solutions. It's not optimal because MDM pushing of updates should work, but I've seen that Apple's part of the MDM triangle frequently is a source of issue. Doing a bit of research I found this to be the case. Nudge does seem fairly easy to implement and does empower your users to install when they want to but to annoy them just enough to make sure the update is installed. The only real obstacle someone might have to implementing it would be to have an Apple Developer account which is easy to sign up for and is $99/year. If you do make apps for your org make sure you don't build them in your own personal account in case you leave the organization in the future. https://www.macadmins.org/ has a #nudge channel that is active. I added one to our Discord https://discord.gg/filewave as well but I don't know that there are experts there on this topic yet. We'll obviously always continue to develop the MDM push of OS updates and do everything we are able to in order to make them as reliable as possible. I think also consider if your organization needs an Apple Caching Server. One reason for updates not to reliably be distributed could be if you have a lot of devices all pulling from Apple at about the same time and perhaps they throttle the connection. A caching server is better for bandwidth and offers more reliability for devices that are inside your network.

Hi @JaredT did you ever get this worked out? Did you go with a support ticket? Curious if you could share the solution as it may help others. If not solved of course https://help.filewave.com or help@filewave.com can be used to start up a support case.

I wonder if this is because when you pick to install an MDM update it really does the notification from FW to Apple to ask Apple to ask the device to update and then it would download to the device and run so perhaps that could take a variable amount of time. Aside from it saying Installed where maybe it's not really yet installed does it eventually appear to install some time after? If you look in FileWave Central (Admin) what does the FileSet status look like when you pick a device? Does it just say "Handled by MDM" like it is waiting to see how it goes? Maybe @Sean will have a thought on this but I'm thinking it's because MDM updates aren't directly pushed from FW -> device that introduces complexity to what is seen. That's not to say that it shouldn't be better, but I'm thinking that's the reason.

The https://supportresources.filewave.com/ has been updated

The PortTester for macOS is updated to reflect the ports for v14.8.0 and beyond. It removes VNC and ZMQ ports replacing them with NATS ports. The Windows version should be refreshed by the time 14.10.0 releases. I have a ticket in to update https://supportresources.filewave.com/ but it's not posted by our IT yet so I'm sharing it here as a zip. FW PortTester macOS 1.0.2.zip

Great that the workaround worked. Service Management is new in Ventura I believe and our editor doesn’t yet have it but you could do a profile from iMazing and bring it in to FW with the same trick. I’ll have to see if 14.10.0 will have Service Management when I get a test release.

I see another way to address this but I wish we did it the way iMazing does. I imported the profile and got the message you got which was expected. I couldn't save the profile. I added Custom Settings and put in a dummy value that I didn't really care about setting. It let me save, and when I export the profile the unsupported section is still in the profile so it's just that our editor doesn't like to save a profile that is -only- an unknown payload, but it will not destroy the unknown payload. It'll keep it and let you save if you have something else in the profile that we do support. @Sean do you see any issue with this approach? I do like your approach if you could use the custom to set the needed keys without doing this trick.

https://www.openssl.org/news/secadv/20221213.txt - OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. However due to the low severity of this issue we are not creating a new release at this time. The mitigation for this issue can be found in commit 7725e7bfe. For FileWave we believe we are not impacted, but we will integrated 3.0.8 in the FW version that comes right after it is released just to be abundantly cautious.