Josh Levitsky

Hi all, We ran in to something that wasn't a bug in 14.9.1, but rather a change in the way Apple numbers apps in VPP so it actually was something that could break Apple VPP in any version of FileWave. The issue is FWRD-1372 Fixed an issue where Apple App Store item with greater than 32 bits ID would stop synchronization with VPP service. It would be seen on any version of FileWave prior to 14.9.2 when you add a new VPP app that may have released in the past couple of weeks. The issue would be seen by VPP sync no longer working because the sync would hang on the new very large ID number. @Pierre-Nicolas posted about it on Tuesday here in the forums. So if you are a hosted customer, and wondered why we hadn't sent out an email yet that we were updating your server it is because we know VPP is critical to so many, and we pushed hard to get 14.9.2 out quickly with this single change. Next week you should start to see our Hosting Ops team reach out to upgrade you and if you are an on-premise customer you can get 14.9.2 right now from our downloads page: https://fwkb.atlassian.net/wiki/spaces/DOW/pages/95125505/FileWave+Version+14.9.2 Thank you for your patience.

RCS is the service that does handle the TV session. Since this is FileWave Anywhere and you are hosted then that would seem odd to see that timeout. To me that feels like something that support may have to see why that is throwing that error. I took a look and your server itself seems to be able to reach rcs.filewave.com so it seems odd.

Hi @HCCSC John H that does make sense and you are right that it's just global for now. Could you maybe submit this to the feedback portal: https://foundry.filewave.com/mod/page/view.php?id=583 along with priority as that is where we are funneling requests but over here is a good place to discuss the pros/cons. I can see where you might have certain apps you want to keep from updating for a period of time perhaps maybe for state testing and then other apps are ok to update so I'm guessing that's one of the use cases, but include in the portal maybe the reasoning you see for the request and it helps.

It would be probably great if someone could open a support ticket on https://help.filewave.com as it seems like this is something we should be handling better. I also mentioned it to @Derek Deckard but if someone could open a ticket it would help track and then we could update the ticket(s) with the outcome. If one of you already reported it then thank you.

https://www.youtube.com/c/FileWave/videos Uploaded yesterday: Q4 2022 FileWave Alliance Q4 2022 FileWave Alliance - Product Development & Professional Services Q4 2022 FileWave Alliance - Ask FileWave Anything & Closing Remarks

@mback thanks for sharing this. With 14.9.1 and the Alliance eMeeting I didn't get to contribute to your answer but thanks for sharing what you worked out here.

Humm I just downloaded it and all is normal but the odd thing is in the above it looks like maybe you added a folder called FWClient that had the .fileset folder. Maybe it's about how you added it. When looking at the Filesets window you can drag and drop the fileset on to it to add it. Ensure that when you download the fileset from the KB that you unzip it and then drag and drop the fileset that should look something like below on to the Filesets window. It should look like this inside when added...

It may make sense to walk through the videos here: https://foundry.filewave.com/course/view.php?id=19 as we just published a step by step on each platform. Remember to sign in to Foundry pick "Login via SSO" and use the same login you use here and for support cases. Maybe that's a good next step since we just published it and it may explain a missing step. Although yes you do use the non-licensed installs of TeamViewer with us but then licensing is handled by us with TeamViewer. One shortcoming of thee way this was done was that you can't access their portal to customize the install in their nice website that makes it really easy to customize graphically so that's one thing lost that hopefully in the future we can work out how to get folks access to.

In your case do they have TeamViewer Host installed? That is needed (or full TeamViewer, but at least Host) because that is what gets connected to.

Really the trick I was using was to move devices between smart groups based on a custom field value that the API was used for. I do see your angle here because that would make there be 1 fileset needed rather than 2. The way I'd improve it because I don't think there is a way to just via API tell a client to remove a Fileset would be to imagine if the 1 Fileset would be assigned via Smartgroup that includes a Custom Field value being a certain thing and then maybe in the script that runs in the fileset it would have to handle changing that field, sleeping for a little and then setting it again. That's about the closest I could think but it's hard because you'd have to spawn a process that isn't attached to the activation script so that it lives and runs through the sleep and meanwhile Filewave would think the Fileset had completed already. In my thinking it through that's how I landed on the 2 Filesets and 2 Smart Groups where you bounce back and forth.

We are moving ahead with FileWave 14.9, and more specifically 14.9.1 will be the public release. For anyone on 14.9.0 you should upgrade to 14.9.1 and if you are hosted we'll take care of that. Emails should go out soon about the new release. Downloads: https://fwkb.atlassian.net/wiki/spaces/DOW/overview If anyone comes across an issue then it's good to reach out to support. A big thank you to everyone internally at FileWave as well as customers who patiently worked with us on making sure 14.9 is solid.

If you are seeing the IP's in FileWave (hosted customers usually see the IP of their firewall for clients inside) then yes that could be a starting point as long as you keep in mind that 192.168.1.x can be SchoolBuildingA but it can also be at Wendy's or McDonalds so just maybe a little consideration of that if devices could be offsite.

Just throwing this out there, but do you use Custom Fields at all to mark which building they are in? Custom Fields are nice because you could have: Building - Walter Isaacson Middle School Grade - ES / MS / HS Role - Student or Teacher And then it lets you make smart groups based on any of the fields or a combination of them. Plus Custom Fields can be updated by importing a CSV file to update the values in bulk. Since I'm an employee at FileWave and I managed assets in a large media company rather than a school I just wanted to throw out that idea and maybe some other customers who are schools will add to this.

We've posted video content in the Foundry https://foundry.filewave.com/course/view.php?id=19 for using TeamViewer to supplement the information from the KB and show all the steps. This continues our efforts to update the Foundry content which is free to all customers. If you have someone in your organization who you'd like to have Foundry access reach out to customer.experience@filewave.com to give them the contact information. The same login for Foundry is also used here to be able to post on the forums. NOTE: Remember when logging in to Foundry to pick "Login via SSO" to be able to login.

Our plan of releasing more widely tomorrow (November 15th) is being pushed back by 1 day to confirm if behavior in 14.9.0 is a bug or specific to a customer. We are in the midst of troubleshooting so need to push back by at least 1 day as we'd not want to release knowing there was an issue.

Our plan of releasing 14.9.0 more widely tomorrow (November 15th) is being pushed back by 1 day to confirm if behavior in 14.9.0 is a bug or specific to a customer. We are in the midst of troubleshooting so need to push back by at least 1 day as we'd not want to release knowing there was an issue if we can take care of it.

While experimenting with the Grafana Dashboard we came across this: https://fwkb.atlassian.net/wiki/x/AYAFBQ and wanted to share it. The issue of not processing YML files for a custom Dashboard would only impact you if the API key for the FW server was regenerated and no longer matched what Grafana had stored in a file. It's an easy fix to delete the token file and on next restart of FileWave then the proper API key would be in the file and everything would work. So if you ever do some security cleanup and regenerate API keys then consider if you have to delete the file as mentioned in the article. For a version after 14.9.0 I believe the plan is to overwrite that file at every startup which would eliminate anyone ever experiencing this. Note this isn't unique to 14.9.0, and could have been something you ran in to with earlier versions.

@Andreas Gluch could you take a look?

I do wonder about ports because in 14.9.0 we went to NATS from ZMQ for the client -> server and client -> boosters as per https://fwkb.atlassian.net/wiki/spaces/KB/pages/80052238/ZeroMQ+replacement+with+NATS so that makes me think it could be port related perhaps but good there is a support case.

It might be good to engage support on it then because it’d be looking at logs and it’ll be a quicker path to resolution. If I can think of something simple I missed I’ll add it here.

Tonight (Wednesday Nov 9th at 2:30am) we'll start to release v14.9.0 to the first wave of customers. If you are hosted and on that list you received an email yesterday with details. If you are on-premise then we will send out the details tomorrow so that support will be prepared. Release notes are posted: https://fwkb.atlassian.net/wiki/spaces/KB/pages/73564161/Version+14.9.x+New+Features+Updates+and+Enhancements+Nov+2022

1) Do you have a kiosk associated fileset already? 2) When you look at client info for that device in the Admin does the fileset show in the list If the first 2 are yes then one thing that can be an issue is if a client is pointed at a Booster that is having communication issues. I suppose check on the first 2 things but likely going down the path of a support ticket is probably the best/fastest route.

Sorry on my delay. I was driving today. Would anything block you from getting to rcs.filewave.com on 443 by chance? That's the server that does the connection between FileWave Admin + Client + TeamViewer. Also fwpn.filewave.com is the other server used in this connection also on 443.

I posted a reply over here on the below thread, but I'd be curious about the outcome of that support case to see if there's anything we've somehow missed.

Do you get the option to start a session and it doesn't or do you not even have the ability to pick to start a session with a device? If you pick to start a session is there an error? It might go faster to go with a support case but then it'd be great to come back here and talk about where things were stuck. As far as something to greenlight your admin you just have to be sure that you've assigned a Team Viewer license to the admin which is done in Assistants -> Manage Administrators and have at least TeamViewer Host if it's mac or windows (TV does also work on Android/ChromeOS/iPad) and make sure you aren't blocking the ports that TV uses. There is a link to TV's ports list on the FW ports list at the top of the page: https://fwkb.atlassian.net/wiki/spaces/KB/pages/4329171/Default+TCP+and+UDP+Port+Usage