Sometimes it's the tiny little things that keep big plans from becoming a reality.
We're trying to simplify and consolidate our eDirectory tree, and make our remote sites easier to manage. The product we've been piloting is Novell's Nterprise Branch Office (NBO or BOMA if you will) v2.0. It has so much potential, yet it falls short in small areas that are important - and would be easy for Novell to fix.
One issue we have, is that it's very difficult to manage PC's and application distribution at sites running NBO. This is because, despite the marketing hype, NBO doesn't actually "cache the corporate tree's eDirectory". It maintains it's own separate tree, and populates it with user and group information from the corporate eDirectory tree - nothing more.
What's worse, if you use PC's with the Novell client at NBO sites, it's even harder to get that PC connected to your corporate tree via ZENworks. (We eventually found an undocumented, unsupported method for doing this, and are testing it now).
The other big problem is that NBO doesn't handle password changes or password policices in the corporate tree very well at all. We should be able to change a password in the main eDirectory tree, and that change should be immediately recognized by NBO - that's not the way it happens. If someone changes it at the far site via NBO's "Virtual Office" portal, that change should make its way to eDirectory.
The reality is that not many users actually use password self service tools proactively- certainly not in our environment, or many that I've seen as a consultant. This means the HelpDesk does a lot of password resets reactively. They can either do this from their admin console, or by opening up a web session to each server where the problem may occur (sounds like the bindery in NetWare 3.x, doesn't it?).
eDirectory and NetWare 4.x were supposed to save us from this mess. You log into the network, not the server. It was a tough concept to grasp at first, but it makes a lot of sense. NBO breaks all of that, sending us back in time some 15 years.
So much for technology making our lives easier...
5 comments:
Hi ZenMaster,
My company has over 50 nbo sites and we love it!
I appreciate that the idea of a distributed directory sounds great until you look at the bandwidth costs.
fyi In my country, Australia we don't get T1 lines - we are using 512K DSL.
We don't use the Netware client in the NBO offices, we use the ZFD Client, we have universal password enabled in the corporate tree and don't have the password issues you seem to be having. We use Middle tier ZEN to publish apps, do remote control via the central tree and do WS imaging by modifying the NBO appliance to support PXE.
We use RSYNC to do away with local backup. Also run NBO on PC level hardware - we have lost about 6 harddisk failures in the 18 months which I guess is the price of using cheap hardware.
NBO requires lots of initial setup but once done it really makes our lives easier.
Thanks for your comments Jeremy. I should probably elaborate.
We use a standard image on all hardware, which we've built, and have placed on our hardware from the factory of our supplier.
Since the majority of our users are at fixed locations with NetWare, the full Novell client is one of our requirements. We want to use NBO at our construction sites - again, the PC's would have the Novell client.
The issues we have with this scenario are as follows:
1) Password policy cannot be enforced from the central office tree out to the remote site.
2) When a mobile user moves between sites - from a jobsite to a fixed office for example, they'll be prompted to change their password if it expires. When that user returns to the NBO site, the new password is invalid - NBO doesn't know it's been changed since it happened outside it's island-tree.
We've learned that using the TREE command in an NBO login script will allow the ZDM 6.5 agent to work properly, but are just now experimenting with it's capabilities. I definitely appreciate your insight here.
That said, there are some simple things Novell could do to make NBO work optimally in sites like yours AND ours. As I've stated before, if it works well here, it will work well everywhere.
Hi ZenMaster,
Adding to what Jeremy said, passwords can be changed at the nbo portal or in the central tree and they sync immediately. We have minimum eDir 8.7.3.4, nmas 2.3.6, nici 2.6.5, central office and eDir servers nw6.x sp5 and zfd401 ir6 and nw65sp3 applied to nbo servers. Passwords can be changed on expiry at the nbo zfdagent login and they sync immediately, so passwords changes are not a problem. There was a problem with earlier releases of the zfdagent and password expiry however. We use cifs for all ZFDAgent logins when mapping nbo and nw6.x servers. For NCP Client we use cifs to map resources on nbo servers and ncp for nw6.x servers.
We have a clever setup with both traditional login scripts and a script which is fires off by zen for zfdagent logins. The drive mappings cover all possibilities. Users can move to any site using NCP Client or ZFDAgent desktop and get all their mapping resources automatically. For us its a seemless solution, for the end user they are unaware of 50 different eDir Trees across our network.
Ross
Hi Zenmaster,
We don't use the tree command as we don't have Netware login scripts.
I do know for some bizarre reason you need to use IP number with the Tree command.
I can't see why you won't be able to get passwords sync happening.
I do think you will have an issue with password policies working with nbo. I'm sure I've seen a TID which says that they are not supported.
Do you ever visit the nbo forum? Its not that active unfortunately. I pop in on occasion
http://groups.google.com.au/group/novell.support.branch-office?hl=en&lr=
fyi My colleague Ross has also responded to this blog item
I really appreciate the input. We'll go back and check our versions, etc.
I'll also have to put together another lab system, as we've not noticed that password changes made in the Central Office tree are picked up at the far end.
Our logger screens consistently show universal password errors, despite the fact that autoprovisioning works properly. This has confounded us and support - this symptom may be meaningful, but we've had no real help in its diagnosis.
If your assertion that C.O. password changes should get read immediately NBO is truthful, we definitely have an issue to resolve.
Thanks again for contributing your experiences!
Post a Comment