Solved

Netware resource allocation/Performance enhancement

Posted on 2003-10-29
20
627 Views
Last Modified: 2010-05-18
The organization (in brief):

4 building campus, all in short walking distance
150-200 Windows 2k Workstations (slowest: PII400, most much faster)
Very Standard Desktop installation (90% configured identically)
2 Mac G4s
6 Netware 5.1 Servers, latest SP (all 1 Ghz/1 GB RAM or better)
Groupwise 6.5
BorderManager 3.6
ZfD 3.2
7 Windows 2000 (Appliation) servers
Switched 10Mb to every desktop
Switched 100Mb to every server

The issues:
-IPX Still Running
-Netware Queues frequently "not connected"
-Printer Setup erratic
-Logins Slow (4.83/4.9 client) or impossible
-Misc other Client issues
-Zen reports not reliable (we have only been able to use it for one software search in 18 months)
-Zen creates errors on workstations
-Groupwise perfomance erratic (from disconnected to excellent)
-Authentication to some servers painfully slow
-Macs unable to utilize network resources (policy established to promote network stability)

Our network has been designed and maintained by a CNE with frequent assistance from Master CNE consultants.

I am not comfortable with our current resource allocation and network performance.  Both have a noticable negative affect on our user's computing experience.

Zen has been of no value to our organization.  It has, in fact, created problems with some of our workstations (ntscan32 errors, resource hogging).  I fail to see any value in NAL (which has caused problems on every single workstation) considering that our installation is so standard.

NDPS was a complete failure, and we are abandoning Netware Que printing for our 20 HP/JetDirect Printers because the queues will intermittently report "not connected" for no apparent reason.  We are moving to direct IP printing.

Our server support time is divided at about 80/20.  80% on 5 Netware servers, 20 percent on twice as many (10) windows application servers.

Obviously, we are doing something (things) wrong.

Here is the challenge/question:  How would you use the resources listed above to create a reliable, stable, and fast Network environment?  I don't expect anybody to address each of the issues listed above...I'd just like thoughts on how it could be redone from scratch to work better.
0
Comment
Question by:sameat
  • 9
  • 7
  • 2
  • +1
20 Comments
 
LVL 34

Accepted Solution

by:
PsiCop earned 65 total points
ID: 9646024
Hmmm...yes, something is very, very wrong. That support ratio is usually the other way around.

Some questions:

1) How is your NDS Tree health? Do the replicas remain consistent, or are they constantly out of sync and having to be repaired?

2) How is timesync doing? Do the servers usually stay in sync, or do they constantly fall out of it?

3) WHY is IPX still running? NetWare hasn't needed IPX for 5 YEARS. Is there a particular reason its still running?

Some ideas about the issues:

A) NetWare Queues "not connected": You said that NDPS was a failure. WHY was it a failure? Did you implement it using IPX or IP? Note that in moving to direct IP printing you lose all ability to manage or centrally control your printing resources. This will eventually lead to higher cost-of-ownership.

B) Logins Slow: Do your clients bind BOTH IP and IPX or just IPX? If they bind both, this can be a problem and cause the symptoms you're seeing. Best solution is to move the servers to IP and ditch IPX.

C) ZEN problems: If the client connection is erratic, this can lead to numerous ZEN problems. I'd be willing to bet that if your client connectivity issues were eliminated you'd be able to find real value in ZEN.

D) GroupWise: Are you running in Direct Connect or Client/Server mode? If the former, then I suspect your problems are related to the client connectivity issues.

I don't know the whole story, but I suspect Step One is to simplify your network environment to eliminating IPX. Get everyone talking one, and only one, communications protocol. Even if this doesn't address all your GroupWise, ZEN and client connectivity issues, it will make troubleshooting a LOT easier.

I'd want to know a lot more about your server and NDS health and configuration before I went any further. Flaky NDS can cause all sorts of problems, so its important that be eliminated as a possible cause. Timesync issues can also lead to wierd side-effects - I just fixed some GroupWise problems that cropped up because of timesync being out of whack.

ZEN and NAL can be an incredibly powerful tools once you have the reliable network environment for them to operate from.
0
 
LVL 35

Assisted Solution

by:ShineOn
ShineOn earned 60 total points
ID: 9646321
1)  IPX still running is not really a problem.  However, NetWare printing through queues is based on IPX and if you want to print using NDPS you must move the protocols to IP eventually, to get rid of queue-based printing.  IPX is a necessity until this is done.

2)  Running both protocols can cause problems with print queues and drive mappings losing connection until a re-login.  I have seen this in cases where the workstation authenticates and logs in using IP but switches that primary connection midstream to IPX.  You have to pick a protocol to get away from this issue.

3) Slow logins can be caused by many things.  You mention it's a 4-building campus.  What is the connectivity between buildings?  Are all of the servers in one location?  Authentication needs to have appropriate access to the NDS partition for the object and licensing.  Authenticating across a slow link will cause a lag.  Slow logins can also be caused by not tweaking the Windows OS to get rid of hindrances put in there by Microsoft, like the 2K/XP function that tries to browse the whole dang network looking for scheduled tasks and shared printers as part of the login process.  There are many PAQ's in this TA on that subject.

4) The ONLY reasons I can think of that you don't like ZEN is a) it wasn't properly implemented and/or b) you've never learned how to use it.  Even in a small network (under 100 users) it can be a godsend, no matter how "standardized" you are.

5)  You mention NDPS as a failure and abandoning NetWare queue printing in the same breath, as though they are tied together.  True NDPS printing is not queue-based.  NDPS printing *can* service legacy queues, but that should be a migration-mode implementation with the goal being pure NDPS.  You apparently have a combination of a partial NDPS rollout and a lack of understanding of how NDPS works.  Once you *finish* the NDPS implementation, you can do as PsiCop recommends and eliminate IPX from your network.

6)  GroupWise is likely the most stable, consistent-performance, low-maintenance email system in existence.  Your GroupWise problems may be related to your other problems.

7)  MACs should be able to use the network, too.  Are you using NFAP or running the Mac client for NetWare?

Are you tied to a specific vendor for your Novell product support?  It could be that the failure is in their capabilities to properly configure a Netware/Zen/BM/GW environment.  As PsiCop said, the support ratio is way off the norm.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9647799
Regarding 5), you can eliminate IPX from client-to-server communication even before you ditch Queue-based printing. Just because Queue-based printing uses IPX for server-to-printer communication doesn't mean you need it for the workstations.
0
 

Author Comment

by:sameat
ID: 9648060
Thanks for your quick responses.

A little more info:  Our internal staff consists of a manager (CNE), a network admin who has very little Novell background, and a PC tech (myself).  I am also responsible for most the windows servers, but they are exceptionally low maintenance and take very little of my time (yes, I know I am lucky, and yes, I do keep them patched).

I don't know how to track the health of the tree, but I can say that we do seem to have a lot of time synch issues.  Our Groupwise server very nearly collapsed (extended periods of 95% + cpu utilization) today while we were working out time synch issues.  It settled down when we got them fixed.

IPX is running mainly because of FUD...our understanding is that rconsole will cease to work (which implies that many, many other things will break!).  By the way, I don't necessarily agree with some of the reasons that I am presenting...I'm just trying to offer an explanation.  Both IPX and IP are bound to 99% of our clients.  All I can offer as a reason for this is that our vendor recommended it (probably as a short term solution that we never followed up on)

Printing:  I do understand that NDPS is not traditional Netware printing.  When I use the term failure, I mean that very early in our rollout of NDPS, users began reporting problems (like all of their printers disappearing intermittently and inconsistencies in printing behavior).  Considering what we felt were limited benefits, we stopped the rollout.  Again, we have a limited number of printers, and the furthest one is a 5 minute walk from my desk.

As far as printing to queues, our network admin has not been able to successfully configure a printer since we went to the web based jet admin product.  While I agree that we obviously need to increase our own knowledge, I have also heard that a lot of people struggle with WebAdmin.  In any event, I see the point that our client connectivity issues are probably leading to a lot of our other problems (including this).

I maintain an Access database for asset tracking purposes, and anytime I have tried to achieve a similar database through ZEN, I end up with more garbage data (machines that no longer exist, machines that have been scanned not appearing).  I just can't get what I consider trustworthy data.  Again, I understand that some of these problems are interrelated.  We do use Zen (in a limited way) to image our workstations, and that seems to work about 80% of the time.

Each of our seven data closets has a 100Mb fiber connection to the server room (even in the remote buildings, which have very few users).  I am very comfortable that our infrastructure would be completely sufficient (if not overkill) if the servers/clients were configured correctly.

As for Groupwise, I have to say that stable and low maintenance are two terms that I could never use regarding our implementation.  We are lucky to stay up for 30 days (in fact, I don't think we have achieved that in the two plus years I have been here).  Novell fans don't like to hear this, but every single one of my users that has used Outlook/Exchange elsewhere begs for it.  I hate outlook/exchange, but I can hardly tout the stability of a system that is regularly down for a day or two.  Most of the problems have been GWIA related, but we also have a lot of strange client errors.  We just upgraded to 6.5 (to work some of this stuff out), and we now have the pleasure of D109 errors (on the old clients) in addition to extreme slowness and in some cases, users completely losing connections (new and old clients).  In conjunction with the upgrade, we eliminated direct as a connection option.  

The Mac issue is a major inconvenience to a handful of our users.  We do allow one to connect via the last novell client, but again, FUD has dictated our policy that even that one will be eliminated for "network stability" reasons.  In this case, the Novell policy of abandoning support has not been helpful.  WebAccess was not a good solution with GW 5.5 (file attaching issues), but the new WebAccess client does look promising.

Obviously, our number one problem is a poor implementation and a lack of expertise.  I have to say that our organization has not been afraid to hire credentialed professionals to consult.  We use the most reputable firm in town, and most of our work is performed by one of three or four master CNE's.  Obviously, they are not serving us well, but our options are limited (do we jump ship midstream?  Go with a vendor we have heard bad things about?)

I am pushing hard for less reliance on vendors and better in house management of the network.  It is difficult for to push for this when I have limited Novell knowledge, and I am so busy putting out fires (getting printing working, fixing GroupWise fonts, and rebuilding machines that won't launch NAL apps consume a major chunk of every day for me) that I can't sit down undisturbed and learn how to do things like improve the health of our tree.  Since we have a CNE on staff, it doesn't seem like I am the most appropriate resource anyway.

This brings me back to the original question, which you have already helped with.   We need to start by gaining the skills we need to improve the health of NDS, and simplify things by eliminating IPX.

Again, thanks for your input so far.  Please let me know if you see any red flags in the contents of this message.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9650879
OK, let's deal with these things one at a time.

"Our internal staff consists of a manager (CNE), a network admin who has very little Novell background, and a PC tech (myself)"

RED FLAG: If he has very little Novell background, what is he doing as network admin in a NetWare environment? Why hasn't he gotten some training?

"I don't know how to track the health of the tree, but I can say that we do seem to have a lot of time synch issues.  Our Groupwise server very nearly collapsed (extended periods of 95% + cpu utilization) today while we were working out time synch issues.  It settled down when we got them fixed."

Without more definition of the "issues", its hard to offer advice. In most situations, one server, usually the Master of [Root], should be designated the Primary Time Server, and the others should be designated as Secondary servers. I'd have to get in there and see what you've got in order to make more-specific recommendations.

"IPX is running mainly because of FUD...our understanding is that rconsole will cease to work (which implies that many, many other things will break!)."

RED FLAG: Yes, that is 100% pure FUD - and another example of why the network admin is incompetent...if he knew what he was doing he'd know that was FUD. While it is true that ditching IPX will break IPX-based RCONSOLE, NetWare v5 and above includes RCONAG6, the Java-based, IP-based RCONSOLE replacement. You will NOT lose Remote Console capability, you'll just have to switch to the IP-based client (RCONJ) supplied with NetWare v5.

"Both IPX and IP are bound to 99% of our clients."

RED FLAG: Definite problem. Pick a protocol, ONE protocol, preferably IP, and stick with that. Get rid of the other one. I suspect that, at the very least, your client-to-server connection and ZEN problems will either vanish or greatly be diminished.

"All I can offer as a reason for this is that our vendor recommended it (probably as a short term solution that we never followed up on)"

RED FLAG: Fire them and get someone who knows what they are talking about.

"Printing [....] When I use the term failure, I mean that very early in our rollout of NDPS, users began reporting problems (like all of their printers disappearing intermittently and inconsistencies in printing behavior).  Considering what we felt were limited benefits, we stopped the rollout."

Given what you've told me so far, I suspect the people setting up NDPS didn't really understand it and so messed up the implementation. In my current environment, we have hundreds of printers scattered across an entire state, all managed quite successfully through NDPS.

"As far as printing to queues, our network admin has not been able to successfully configure a printer since we went to the web based jet admin product.  While I agree that we obviously need to increase our own knowledge, I have also heard that a lot of people struggle with WebAdmin.  In any event, I see the point that our client connectivity issues are probably leading to a lot of our other problems (including this)."

Don't underestimate the influence of incompetence. Note that when I say "incompetence" I don't mean "stupidity". Incompetence can be alleviated through training and experience - I am incompetent as an Apple network admin. If I got some training and experience that would change. Just trying to explain that when I say he's incompetent I'm not calling him stupid, he just needs to develop certain skills.

But I think you're right in that the root cause of a number of your problems is basic connectivity issues.

"I maintain an Access database for asset tracking purposes, and anytime I have tried to achieve a similar database through ZEN, I end up with more garbage data (machines that no longer exist, machines that have been scanned not appearing).  I just can't get what I consider trustworthy data.  Again, I understand that some of these problems are interrelated.  We do use Zen (in a limited way) to image our workstations, and that seems to work about 80% of the time."

I really think a lot of this can be tracked back to either the basic connectivity problems or problems with NDS.

"Each of our seven data closets has a 100Mb fiber connection to the server room (even in the remote buildings, which have very few users).  I am very comfortable that our infrastructure would be completely sufficient (if not overkill) if the servers/clients were configured correctly."

Sounds like your physical plant and Layer 1/2 connectivity is fine. Your problem is further up the stack - say about Layer 8.

"As for Groupwise, I have to say that stable and low maintenance are two terms that I could never use regarding our implementation.  We are lucky to stay up for 30 days (in fact, I don't think we have achieved that in the two plus years I have been here)."

RED FLAG: That is ridiculous. Something is very, very wrong in how GroupWise has been installed and/or maintained.

"Novell fans don't like to hear this, but every single one of my users that has used Outlook/Exchange elsewhere begs for it."

That's because they have no idea how much it costs to own.

"I hate outlook/exchange, but I can hardly tout the stability of a system that is regularly down for a day or two.  Most of the problems have been GWIA related, but we also have a lot of strange client errors.  We just upgraded to 6.5 (to work some of this stuff out), and we now have the pleasure of D109 errors (on the old clients) in addition to extreme slowness and in some cases, users completely losing connections (new and old clients). In conjunction with the upgrade, we eliminated direct as a connection option."

OK, finally, some good news - you eliminated Direct Connect. Shoulda been done years ago (it was available for elimination back in GroupWise v5.0), but better late than never, I suppose.

However, given the lack of competence elsewhere in the network administration realm, I'm worried that before the upgrade the network admin failed to preen the GroupWise databases and eliminate all errors. Upgrade 101 class - for ANY product - tells us that you only upgrade a healthy environment, not one that's full of problems. If its got problems, you fix them first, then do the upgrade. I'm worried that didn't happen here.

Direct Connect was notorious for allowing users to corrupt the GroupWise databases. If the damage has not been fixed, it would explain why you continue to see the problems even after upgrading. Has he ever done a "top down rebuild" of GroupWise? Probably not - if you ask him I have $5 that says he'll return a blank stare.

"The Mac issue is a major inconvenience to a handful of our users.  We do allow one to connect via the last novell client, but again, FUD has dictated our policy that even that one will be eliminated for "network stability" reasons.  In this case, the Novell policy of abandoning support has not been helpful.  WebAccess was not a good solution with GW 5.5 (file attaching issues), but the new WebAccess client does look promising."

I think what ShineOn was asking about was how to the Mac's connection for file and print services? There is a Macintosh Client for NetWare, roughly equivalent to NetWare Client 32 for Windoze.

Yes, Novell's on-again/off-again support for the native Mac GroupWise client is annoying. But your "network stability" issues have nothing to do with it.

"Obviously, our number one problem is a poor implementation and a lack of expertise."

You have a facility for understatement. :-)

"I have to say that our organization has not been afraid to hire credentialed professionals to consult.  We use the most reputable firm in town, and most of our work is performed by one of three or four master CNE's.  Obviously, they are not serving us well, but our options are limited (do we jump ship midstream?  Go with a vendor we have heard bad things about?)"

Perhaps if you told us where you are, geographically, an Expert here could recommend specific people who they know to be competent. I hate to say it, bnut it doesn't sound like the folx you've been using know what they are doing, or they do but the local admin has not been properly implementing their recommendations.

"I am pushing hard for less reliance on vendors and better in house management of the network."

The key to achieving this is training - something management does not often like to do.

'"Since we have a CNE on staff, it doesn't seem like I am the most appropriate resource anyway. "

Yes, but is he a manager or does he do CNE work?

"This brings me back to the original question, which you have already helped with.   We need to start by gaining the skills we need to improve the health of NDS, and simplify things by eliminating IPX."

Yes, I think those are two good areas to start in.

I hear about situations like yours and a cringe. I'm glad to hear you're not blaming the NOS, and that you realize exactly where the problem lies.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 9651225
The first thing that comes to my mind is - yes, you have a CNE on staff.  Is his CNE current?  What version of NetWare was he certified for?  Does he do ANY hands-on management of the NetWare/NDS environment?  

If this guy got a CNE3, for instance, and has never updated to CNE5, you really don't have a CNE on staff.  To maintain CNE status, you have to keep current.  A CNE4 won't help much with NetWare 5 and up, unless you have made the effort to keep current.  NetWare has changed more than many people realize, and having a manager with an outdated CNE is worse than having no CNE at all.

Secondly, regarding GroupWise vs Outlook:  A lot of people "like" Outlook because they use OE at home.  Some people have only used Outlook at work and may need a bit of training to "get" GroupWise.  My experience is that people that have used both, and have been through proper user training, prefer GroupWise to Outlook.  

Part of their "asking for Outlook" may also be the instability in your current environment.

Also, regarding IPX, there are a couple of products that run on the server side in NW 5.x that may still use IPX/SPX based calls, so although you can comfortably remove IPX from the client, you may want to do some research before removing it from the server.  As PsiCop said, NDPS servicing traditional queues can be done without IPX to the client - but it still needs IPX to the printer.  If you are doing ANY traditional queue-based printing, you still need IPX on the client until those printers have been converted over to NDPS.

I concur with PsiCop.  You need to get some training in there.  First and foremost, though, you need to get some competent help to get your problems fixed.  I know it costs an arm and two legs, but if you can't get good results from consultants in your area, you can contract with Novell Consulting to send their own ppl in to fix it.  They can do stuff that even MCNE's can't .
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9651265
ShineOn's last comment reminded me of one other thing I wanted to say - if I were in your shoes, I'd think seriously about picking up the phone, calling Novell (1-800-NETWARE), tracking down your company's Novell sales rep, and "suggesting" to him that he needs to pay a visit to the IT management of your company, and to bring along the local Professional Services Engineer when he does. Your company doesn't seem to be afraid to spend money on consulting services, perhaps its time to quit messing around.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 9651463
Oh, and about the Mac -

The direction Novell is going is away from proprietary clients, toward cross-platform compatibility.  With NetWare 6 and 6.5 the facility comes with it to provide native file/print access to Windows, Mac and *nix.  I'm pretty sure you can get the NFAP for 5.1.  That would allow native access for the Macs without futzing with the old NetWare Client for Mac.

Regarding the lack of progress on the GroupWise client side for Mac, the direction they are taking is, I believe, a universal Java-based client that can run on any platform, including Mac and *nix.

I think PsiCop is more in tune with that than I am.
0
 

Author Comment

by:sameat
ID: 9655115
Thank you both for taking the time to write such thorough responses.

I do have some closing observtions:

1) Based on personal experience (I am an MCSE) and my current work environment, it is pretty clear that certifications are not worth the paper they are printed on.

2) I intentionally avoided blaming the NOS for serveral reasons.  I would have to be blind not to see that the problem truly is incompetence (I appreciate the clarification of that term), and I would have to be dumb to ask for expert assistance and insult the area of expertise.  However, I have to admit that it is disheartening to see such a large investment result in a mess like this.  I can't help but think that Novell has a tough road ahead of them when so-called experts that they certify are incapable of providing reliable solutions with generous resources (not that MCSE's are any better).  We may be an isolated case, and I fully understand that our incompetence is to blame, but I suspect that there are others in similar situations.  I hope for the sake of competition and superior technology that there aren't too many.

My next task is to take the information that you have so graciously provided and try to clean up this mess before beancounters step in, fire the three of us and migrate to a Windows environment.  That call to Novell will be happening soon.

Wish me luck!
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 35

Expert Comment

by:ShineOn
ID: 9655433
sameat -

The problem is not that Novell is certifying incompetent people.  The problem is that too many consulting firms are providing incompetent people to their customers.  There is likely a higher percentage of incompetent MCSEs than incompetent CNEs, if I may be so bold...

At the risk of sounding paranoid, the problem is that most consulting firms these days are Microsoft-centric and do not properly balance their priorities for the customer's sake, but rather for their own bottom line's sake - which tells them to promote and sell Microsoft products because that's where their ongoing income stream is.  If they were truly customer-focused they would configure whatever the customer has to the best of their abilities, regardless of the vendor or partnerships with a vendor.  They would not do what was done to your environment.

Which is where I agree with your earlier statement that the company is better off having their own trained personnel on staff.  They have a vested interest in making it WORK rather than a vested interest in ensuring future billable time.

That said, it would have been nice had you split the points.  I think we both contributed a lot.  Not to take anything away from PsiCop's contributions, but, if you are thanking us both for thorough responses, you should thank us both with points as well...
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 9655480
Oh, one more thing.

The dictionary/encyclopedia/thesaurus half of my brain has been sending up smode signals at the use of "incompetence" in this thread.

Competence and incompetence both relate to how well and efficiently you can perform a task.

Incompetence can be a result of ignorance, or as a result of stupidity, or a result of any other number of physical or mental factors.

Competence means that you know how things work, and do the right things to make them work, knowing the whys and hows of accomplishing the desired result.

Incompetence is the inability to accomplish the desired result, for whatever reason, excepting external forces.

What should have been discussed here is not the i*ncompetence* of the network admin (or the consultants) but the *ignorance* of the network admin.  The admin might be very competent, yet still fail at getting JetAdmin to work because of ignorance.  If the network admin can't do a dang thing despite being given all the training and help resources available, then the admin is incompetent.  If the reason the admin is incompetent is because the admin is mentally unable to grasp the concepts no matter how intense and complete the training and support, then the admin is stupid.

Sorry, but I just HAD to get that off my chest...
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 9655488
Typo.  That's "smoke" signals, not "smode" signals.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 9655495
And the asterisk should be before the I in incompetence, rather than between the I and N.... ;)
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9657617
sameat,

I appreciate you awarding the points to me. I do agree with ShineOn that he made substantive contributions to this Question and that you should consider awarding a portion to him. You can do this by posting in the Community Support TA (doesn't cost you any points to do this) and asking a Moderator to split the points. Remember to provide a link to this Question.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9657620
ShineOn, one of these days you're gonna have to start proofing before you post. :-)
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9657682
sameat,

"Thank you both for taking the time to write such thorough responses."

You're welcome. That's what we're here for.

"1) Based on personal experience (I am an MCSE) and my current work environment, it is pretty clear that certifications are not worth the paper they are printed on."

I agree and disagree. A cert backed by several years of experience is worth something. A "paper" cert is, I agree, worthless. Novell certs used to mean something - the tests were difficult, and while they were open book, if you had to refer to the books you would not be able to complete the test. You either knew it or you didn't.

Lately, however, companies - and I mean all of them - have looked to certification as a revenue source. They really don't care about the quality of the certification, they just want the slice of the class charges and testing fees.

"2) I intentionally avoided blaming the NOS for serveral reasons.  I would have to be blind not to see that the problem truly is incompetence (I appreciate the clarification of that term), and I would have to be dumb to ask for expert assistance and insult the area of expertise."

These things put you a cut above a number of others asking for help in this forum. :-)

"However, I have to admit that it is disheartening to see such a large investment result in a mess like this."

I agree completely. I see situations like your described and I want to say "Where are you, I'll be on a plane tomorrow and come fix it all for you" because I have gone in and cleaned up very messy NetWare environments. And at the end, I delivered a reliable, smoothly functioning network. But I don't think my current employer would understand.

"I can't help but think that Novell has a tough road ahead of them when so-called experts that they certify are incapable of providing reliable solutions with generous resources (not that MCSE's are any better).  We may be an isolated case, and I fully understand that our incompetence is to blame, but I suspect that there are others in similar situations.  I hope for the sake of competition and superior technology that there aren't too many."

Yes, and as ShineOn mentioned, there's a very simple economic reason for it. If the VAR tech staff comes in and creates a very reliable, stable environment, they don't have a source of billable hours after that. Hence, they have no incentive to do what it takes to create that. I don't meant to bash Microsoft, but this is the reason so many VARs like to recommend Redmond's products - they KNOW they will break, require constant patching and maintenance, and are easily hacked. In short, the VAR is practically guaranteed a steady stream of future billable hours by recommending the Microsoft environment. You see, from time to time, industry articles where VARs quietly (and usually anonymously) admit this. Its a very unhealthly culture that's been created, and probably one of the chief reasons I find it difficult to be really successful in that line of business, because I couldn't do that to a client.

"That call to Novell will be happening soon."

Glad to hear that. Sometimes you can also get them to do some "free" consulting and/or training by offering your company to be a "success story" for them.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9670787
PepsiCop?

I generally drink Coke products.....
0
 

Expert Comment

by:YensidMod
ID: 9672294
PsiCop,
   Sorry!  :)  I spellled Gns name wrong once, Gris.  That is a bad word in Swedish. :)

Yensidmod
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 9876190
sameat,

If you're still around, its been a month, and I'm curious if any resolution came out of this.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

In this article, I will show you HOW TO: Install VMware Tools for Windows on a VMware Windows virtual machine on a VMware vSphere Hypervisor 6.5 (ESXi 6.5) Host Server, using the VMware Host Client. The virtual machine has Windows Server 2016 instal…
In  today’s increasingly digital world, managed service providers (MSPs) fight for their customers’ attention, looking for ways to make them stay and purchase more services. One way to encourage that behavior is to develop a dependable brand of prod…
This video discusses moving either the default database or any database to a new volume.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now