Synchronous Windows Logon Scripts with Novell Client

I have several customers that have a Novell Netware based network with a Windows 2000 domain. The primary network client on the workstations (Windows 2000) is the Novell client. The user logs into the novell client first. Since the username and password match the Windows domain and the computer is part of the Windows domain, the user is logged into Active Directory as well.

On the Novell side there is a logon script, as well as on the Windows side (BAT file, executed from "Logon Script Path" in Active Directory). The Novell script executes, then the Windows script executes while the desktop is loading.

The problem that I am having is that I want the Windows script to execute BEFORE the desktop loads. In a pure Windows 2000 environment, I can configure this by changing the group policy and enabling "run logon scripts synchronsously". Then the logon script runs BEFORE the desktop loads. However, with the novell client installed, the workstation seems to be ignoring this policy setting.

How can I get the Windows logon script to execute synchronously on a Windows 2000/XP machine with a Novell client?

Yes, ZEN will work with the not-really-a-Directory-Service-but-they-call-it-one-AD just as well as it will with eDirectory, altho you may miss eDirectory's reliability, time-sync, ability to partition,

I have to say, I don't understand why you want two different scripts like that. All you're doing is doubling the administration burden. What's in the Windoze-side script that can't be added to the NetWare-side script?

Personally, I'd look at simplifying the script environment first, rather than making it more complex.

If you're intent on creating a high-maintenance environment, you can always call the .BAT file from the NetWare-side script. --> @\\PATH\TO\SCRIPT\SCRIPT.BAT

This environment is high-maintenance anyway because you must maintain double sets of usernames and passwords. I need to keep the environment separate for support reasons. There must be a way to get the windows logon script to execute synchronously.

"This environment is high-maintenance anyway because you must maintain double sets of usernames and passwords"

No, you don't HAVE to. You may have CHOSEN to do so, but you don't "have" to. If you used a tool such as Novell Identity Manager (formerly DirXML 2.0, http://www.novell.com/products/nsureidentitymanager/), you could easily synch usernames and passwords across the platforms. DirXML even lets you set up Role-Based Policies, with which you can create a user in NDS and they will be populated into AD and put into all the proper groups and given all the proper file permissions and the passwords synched.

I can't imagine how keeping the environments separate could possibly improve the support - all I can see that doing is driving up your support costs. I got $10 that says you could get 100% ROI inside of 12 months with DirXML.

As to the way you want to do things, as best I know, Windoze is going to do the network connections in provider order. I don't think you can change that. What's wrong with calling the Windoze batch from the NetWare login script? Specifically, I mean?

I must agree that it seems a tremendous waste of time and effort to have both environments provide login scripts - especially when NetWare login scripts are much more powerful and easier to use, and can be associated to a user, a profile or at the container level (which, unlike eDirectory, isn't a valid "natural group" in AD.)

Maintaining double sets of usernames in a small environment is trivial, and password synchronization at the client side is automatic with client 4.9x. You also get more authentication options with eDirectory 8.7.3 because it includes the full-blown NMAS product, making it easier to use things like LDAP (which is fully supported in NetWare but isn't in Windoze) and allows for multiple authentication levels based on the combination of "proof of identity" used. In other words, you can have a simple password give you basic access, followed by a smart-card granting you higher-level access, followed by a biometric authentication granting you even higher access.

In a large environment with a lot of A/C/D activity Novell Identity Manager is a great value, as PsiCop said.

So, if there is something that CAN'T be done via the NetWare login script, then it makes sense that you'd HAVE to use both, but if there isn't a real requirement (as opposed to a percieved requirement) to have something done in a Windoze login script, don't.

I appreciate your concern, and I already know that you can modify the Novell logon scripts. But this does not answer my question. Lets please assume for the moment that the scripts must remain separate, for whatever reason (even if we do not like it).

Here's my question again: How do you get the Windows scripts to run synchronously when a user logs into a workstation using a Novell login?

I can enforce this using a group policy under Active Directory (run logon scripts synchronously) when the user logs into a workstation using the Windows login. Is there a way to enforce this same policy in a novell netware environment?

" Is there a way to enforce this same policy in a novell netware environment?"

I don't believe so. Not with the stock NetWare environment. The issue is that the Windoze login is happening after the NetWare login, and your design, for whatever reason, keeps the NetWare envionment ignorant of the Windoze environment. So the logins happen sequentially, and the scripts are executed sequentially.

If there is such a way to do what you want, I suspect it would be dependent on Novell Identity Manager (formerly DirXML, http://www.novell.com/products/nsureidentitymanager/) as a unifying tool for the environment. Without that unification, I don't see any way to get the scripts to execute synchronously, altho I confess I've never tried to do what you want and so can't 100% exclude the possibility. DSPoole might know of a way, if he's got the time to spare right now (he's busy with a nation-wide NetWare v6.5 rollout). Hopefully he'll chime in.

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

I don't. I ignore the Mickey-Mouse Windoze Policies, which depend on files located on a server. If that server is down or unavailable (perhaps a WAN link is down), then the policies fail to get applied.

By contrast, Novell's ZEN-delivered Policies, which we DO use, are not stored in files on a server. They're stored in the Directory Service, and do not rely on a specific server to be available (or, more to the point, in a properly-redundant eDirectory - not necessarily NetWare - environment, the loss/unavailability of a specific server does not affect distribution and enforcement of the policies). Give me ZEN's Directory-Service-delivered policies any day over the 80s-retro files-on-a-server that we see in Windoze.

So are you saying that I can enforce Windows group policies using ZenWorks the same way I can use Active Directory to enforce Windows group policies in a pure Microsoft environment? If this is so, then I believe you've answered my question. Please confirm. Forgive me, but I have never used ZenWorks.

Yes, ZEN will work with the not-really-a-Directory-Service-but-they-call-it-one-AD just as well as it will with eDirectory, altho you may miss eDirectory's reliability, time-sync, ability to partition, ease of making servers host/not host directory services, and multi-platform native support. But Novell will give you CHOICES, whereas Redmond attempts to lock you into their one way of doing things.

I can't say for sure that ZEN will be able to enforce Workgroup Policies the way you want with AD as its sole DS - I have never built a network that relied on AD like that. We always turned to the much more mature and technologically-advanced eDirectory for critical operations.So I can't guarantee you have that specific functionality available to you in a ZEN environment relying on AD. My best suggestion is that you contact Novell (1-800-NETWARE here in the US) and ask for a pre-sales engineer, or you get up with your local Novell sales rep or local Novell VAR and ask them. If nothing else, they'll be in a position to let you try the software before you buy it.

eDirectory is Novell's product. It began as a product called "NetWare Directory Services" circa 1994. It then was renamed "Novell Directory Services" circa 1997 when they started to port it to other platforms (Solaris was one of the first, I think). Along about 2000, while AD was still in diapers, they changed it again to eDirectory. Novell was doing Directory Services back when Micro$oft was busy ripping Stac off for disk compression and suckering rubes with their claims about NT's reliability and stability (and then 6 years later, the rubes' cash safely in the bank, Redmond admits that NT's security is uncorrectably flawed).

The biggest structural difference between eDirectory and the original NDS is the database engine. Other differences include the fact that eDirectory runs *natively* on about 10 different platforms (Solaris, RedHat Linux, SUSE Linux, AIX, HP-UX, NT, W2K, W2003...) and there's been no upper limit found on the size of and eDirectory database (they gave up when they hit 1 billion objects, I think). AD can't even handle more than 5000 users in a group (so if you're a multinational with 10K employees enterprise-wide and want to have an enterprise-wide group in your directory service, you can easily do it in eDirectory, but with AD you have to create multiple groups and then "nest" them, making management harder). And that's just one area in which AD falls way short of the mark that eDirectory set years ago.

0

Featured Post

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Owning a franchise can be the dream of a lifetime. It provides a chance for economic growth. You can be as successful as you want. To make your franchise successful, you need to market it successfully. Here are six of the best marketing strategies …

Is your Office 365 signature not working the way you want it to? Are signature updates taking up too much of your time? Let's run through the most common problems that an IT administrator can encounter when dealing with Office 365 email signatures.