One of the WHD features is the ability to push notifications to your mobile phone using the Apple Push Notifications Service. This service requires a certificate which expires today. If you want to continue using these notifications you need to install the new certificate availalbe from your customer portal.
Click on License Management -> My Downloads (under Web Help Desk licenses information) -> scroll to Additional Downloads and click Download button next to "Apple Push Notification (APN) Certificate".
First: considering that this task needs to be done regularly as the cert expires, you guys really need to make it something that is easily installed via the WHD web interface, or at worst using a one-step updater app run on the server box that does it all for you. All this .jar renaming and unzipping and rezipping is ridiculous. This kind of tedious stuff should not be required: it's laziness on the part of Solarwinds (not taking the time to build a cert-replacement function into the GUI or at least build a little updater) driving this PITA stuff on the customer's part. Not cool.
Anyway, I messed with this for over an hour tonight, trying different things on my OS X WHD 12.3 server to see if I could figure it out, but it's not working.
Basically, I re-did the .jar file as described in the readme, using the native zip and unzip commands in the OS X Terminal to ensure that things were bog standard (I used the -X option on the zip command to exclude OS X metadata, just in case that could be hosing things up). I made the permissions on the new file match the other files in the lib directory. All to no avail: with the modified .jar in place, WHD just displays the following 404 error.
Putting the original .jar back in place gets things going again, but it's got the old push cert.
Can QA please test this and give us proper instructions on how to replace this cert without breaking the .jar?
type Status report
description The requested resource is not available.
I hear you and we have a plan how to get rid of this completely or at least don't make it such a hassle. Please stay tuned!
Let us look into this, where is the problem. We might reach out to you offline for more details.
Thanks for your reply, Peter; good to know that this process will be getting less of a pain going forward.
In the meantime, however, it's been a week without any updates here and no offline contact....is there any progress on this? We'd really like to get our push notifications working, since it's going on a month without them now.
We reproduced that problem on OSX using terminal zip tool. However zip/jar file created from OSX GUI works well. For now we are going to include this information in the readme file. However we see place for process improvement and simplification for longer term.
Sorry, Marek, no go. I tried the built-in "Compress" functionality that OS X provides (by right-clicking the folder and choosing "Compress <filename>" from the contextual menu) to re-zip the file but the exact same thing happens.
I suspected that this would be the case, because there should be no functional differences between the Terminal's (i.e. unix's) "zip" command and OS X's "Compress" functionality ("Compress" apparently uses "ditto -c -k" instead of zip): they produce the same result (as long as you're ok with OS X metadata, which "Compress" has no option to exclude).
So there's some other difference between your test system and my production system, or there's some other difference in what we're doing. Note that I'm on OS X 10.10.4 right now. You're welcome to remote into my system to take a look and give it a try if you like, to see if you can identify the issue; please contact me if you'd like to make arrangements to do that.
At this point, I still don't have a working production push certificate after more than a month.
I performed the actions as described in the Read Me for a Windows Server installation and it produced the same error, I used 7zip for repackaging the zip. I tried zipping it from several different Windows-based (Server 2012 R2, 7, XP) machines as well with 7zip to no avail. Thoughts? I am going to run through the process again with other utilities to see if I can't get this to work properly.
After a few more attempts, I was able resolve my issue with using WinRAR for packaging the zip file back. Not sure if this helps in isolating the issue, or, determining a better means of replacing the certificate.
It's surprising that a subsequent Hotfix hasn't been packaged up with this new certificate included in it, removing the issue of different platforms and zip utilities.
One thing to note, as I continued to test what could be the cause and failure of some ZIP functions over others, I found that the way you select the folder and contents to be zipped could result in a different structure within the ZIP file. For instance, when packaging the temp folder, you will need to go into the temp folder and select the contents to be zipped. I found that in my haste with 7zip and other utilities, it assumed the primary directory of temp instead of the contents inside temp, so I made sure I was within the directory each time I Zipped the contents (or navigate and select within the ZIP utility the folders/files). Not sure if I am making sense in this regard. See examples below. It maybe worth checking to see what the inside of the ZIP/JAR look like after you have repackaged the contents.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.