10-13-2010 10:23 AM
I would like to solicit feedback from this group (switching) on what your top 3 things we could do to improve your ability to solve problems using the resources on our web site.(http://www.juniper.net/customers/support/).
Please be as specific as possible - for example "fix the !!#@!$ KB" isn't as useful as "I couldn't find good answers when I searched the KB for LLDP-MED"
11-03-2010 07:24 PM
One things that kind of gets me is the inconsistency. As an example, the support main page has a link to search for "Junos Defect Search" and then on the product specific page for the EX4200, the same search is now called a "JUNOS Bug Search". Two reason why this bothers me. 1. In one place it is a bug, in the other it is a defect. Decide what it is, and leave it at that. Everyone I know just calls it a bug. 2. One place it is "Junos" the other it is "JUNOS". A decision needs to be made on that also, because I see both ways all the time on Juniper documents. My understanding is that "JUNOS" is an acronym for "Juniper Operating System" If that is the case, then isn't "JUNOS" the correct way write it?
I truly understand that my example is a minor problem. But to me, consistency leads to trust, and trust is something that every company needs.
11-04-2010 03:12 AM
Excellent points, especially that of trust. The "right" form of Junos is "Junos" - however that form was established as part of our new branding campaign last year. Prior to that, you'd see Junos, JUNOS, JunOS, etc so we adopted the formal brand for exactly that reason.
That said...it then introduces the challenge of what to do about the 1.5 million+ documents already on our website. Short answer is we fix them, but my army of highly trained cockroaches can only move so fast
(Similarly you'll see many parts of the site with brand elements from 2+ years ago - the infamous cartoons and such. Those are also being re-worked. Very busy cockroaches indeed...)
re: Bugs vs PR's vs Defects vs... - we're working on that too. PR means "Problem Report" which I happen to like because it correctly reflects that - when first reported - these "things" can be bugs, can be feature enhancements, can be "working as designed", etc. But..as you point out the common vernacular of "bug" is pretty clear to everyone. We'll pick one and stick with it
11-04-2010 05:03 PM
One useful thing would be that for all the secondary domains that point to juniper.net and support.juniper.net (eg neoteris.com) make sure they redirect to juniper.net, not serve as additional authoritative domains which just causes google pollution.
I think this may have now mostly been done, but someone trawling the web server config is still probably worth it.
11-04-2010 06:48 PM
Not directly related to juniper support, but is there a way to influence the Google searches as in "configure ipv6 default route juniper" to goto the tech docs of a recent Juniper code train? Something a little more in Junipers control is maybe have a radio button for the platform that you are on ie. List a Junos button for EX, J & M, then a ScreenOS button. This could be done on the second screen of the search as well.
11-09-2010 04:44 AM
That's a great observation and suggestion. We've got over 100 sub-domains and TLD's and they've gotten a little out of control, so our IT department is combing through them now to determine when we should be re-directing vs not (for example we have to preserve services.netscreen.com to support legacy equipment but it should re-direct if referenced directly)
11-09-2010 05:29 AM
Another good suggestion. Normally you use a sitemap to influence Google, but the options are limited. There is a "priority" attribute that might be of some help but I can't say for sure. But I will pass this on to our techpubs gurus and see if they can come up with anything.
Our KB search does a little of this - first because we generally only index the last 3-4 versions of the documentation. Second, it's got a "boost" which will prefer the most current version, but this only works when the content is an exact duplicate - we've been making a lot of changes to the documentation from release to release, so this is increasingly rare.
11-18-2010 06:03 AM
I can't seem to connect with actual juniper employees! I had posted the following question :
But am unsure how to get the attention of an actual juniper expert , its probably and easy answer for them too.
11-18-2010 02:31 PM
Welcome to the forums. These are the community support forums where fellow users bounce problems or implementations off of each other. There are a number of Juniper employees that participate here, but this is not the formal avenue for support on real problems or your serious, time sensitive issues.
In short, this is NOT "on-line support" from Juniper.
For those you open a case with JTAC on the support portal.
02-20-2011 08:23 PM
Any feedback on the new support portal? We had one hitch Friday where a secondary index page wasn't updated for 10.4, but other than that...it's been very quiet...
12-06-2012 07:43 PM
03-14-2014 02:18 PM
all KB Articles should list the JUNOS version that this KB article applies to. i.e this solution was tested on x.y.z ver and applies to version a.b.c to x.y.z
Also a diagram in KB Articles would help
03-15-2014 12:17 AM
Just before I comment, searching and renaming the all the junos is really really very easy. Use a search and replace the entire site for all instances of juNoS JUNOS etc and replace with Junos just use case sensite. Done in a few hours. I will get to my suggestions later.
04-15-2014 06:12 AM
How about we keep a data base of the software customers are running from their downloads, so we can inform them when there is a software bug in code they may be running. For example; bug identified that reboots line card in EX8200 chassis running Junos 12.3R3,R4 ----> notify customer X since they are in the data base as have downloaded code noted and have EX8200's on support contract.
Seems it shouldn't be too difficult to automate and get this done. Being proactive would go a log way here!
05-23-2015 09:07 PM
I'm very new to Juniper, but I have been in the industry for 23 years.
My suggestions are based around difficulties new people may have. This may be very influencial on growing a new customer segment beyond ISPs and Large enterprises.
1.) Make the login on the main Juniper Website visible, not invisible behind clicking on Support, especially more invisible since when hovering over support it brings up a huge menu that covers the whole page and implies that login would be somewhere in that popup menu--which it isn't!
2.) When calling to buy something simple like device brackets, don't make it impossible to get part numbers and even more impossible to get through to someone who actually KNOWS where someone can buy them. This is very alienating and makes someone want to hate Juniper. Try 5 phone calls and finally getting a phone number of a reseller, only to have the email with the phone numbers not have phone numbers but instead a form to request help yet again, only to have to call back yet again, to finally get a phone humber and then, only to have the reseller never return a call or send me an email after I explained what I was trying to buy. It is literally like the customer or the network engineer (which is what I am) doesn't even exist to Juniper sales via support. (Not that I have found any other path.) And it is like the little guy doesn't exist to the reseller of Juniper goods.
3.) Even tho I am getting my Juniper certification, at this point I would never voluteer to a customer to buy Juniper after how badly I have fallen through the cracks. I am not angry or vengeful, but I seriously don't get a feeling there is a real path to any resolution except the spotty online documentation that is either there or it is not, and Technical remote sessions with Juniper Engineers. This is a huge gap in between. It is like the early days of IBM, they were God condescending to the useless and supervluous masses. I went to some of there conferences in the 80's and was very offended by their approach to the public.
4.) For those common practices that Network Engineers have been doing for decades on Cisco equipment, such as pinging the loopback, have documentation that clearly details how to do it on a Juniper device. There are a number of common practices in the industry that can take days and weeks to find answers to as to how to do it on a Juniper device. And I am not talking about replacing one command for another, I am talking about industry standard networking practices that Juniper people must be aware of that they don't make an effort to advertise how to do on their platform. There are so many MYSTERIES on Juniper equipment. (like the solid red lights on my PIMs). Why can't someone just know that it does or doesn't mean the PIMs are bad? Why does it always end up being so complicated and mysterious? I have looked for a week now and cannot find a definitive explanation (or any further explanation) behind the stock definition: On steadily Active with a local alarm; device has detected a failure. Is this a software failure, a hardware failure on the PIM, a FPC failure, a router motherboard failure??? This seems to illustrate the normal case: There is hardly any information on anything beyond the surface online documentation. Make more good content available for JUNIPER AND junos. This is my opinion.
Maybe I don't know the resources you have very well, but being a Network and a Systems Engineer I kind of know my way around finding information and doing technical research. There are my gut feelings so far, SORRY.
I am thankful that you have taken the time to ask for this feedback, I hope you can make a difference.
P.S. I am also thankful for the individuals who have given me help on this forum. These individuals clearly are very caring and very helpful. They have a commendable attitude and practice. THANK YOU.