Zen DLU vs AD Domain

I'm working on a situation which maybe common these days, but I'm looking
for clarification.
We're using Zen 6.5, users with DLU policies logging into XP clients and
Nwclient 4.9.1
We have used DLU to manage local workstation accounts and it works well.
Our XP workstations will be joining a domain soon and our orgranisation has
many sites.
We think the domain joining will be carried out on a site by site basis.
For users on a site with workstions joined to a domain, they will have the
Zen DLU policy removed, and login to eDir and the domain using the same
account....great.
We plan for users without DLU who login to a site with non-domain
workstation, could choose a location profile that has the NT domain field
blank (and therfore login local), and login to the workstation using a local
account pre-setup for them.
But here's the infernal question...
A user WITH DLU login, into a Domain workstation.....This sounds bad!!
How much should I worry about DLU trying to create accounts on a domain
joined workstation??
What can I do in that case????
Thanks

Push this key to all PCs that are on the Domain.
http://support.novell.com/docs/Tids/.../10071463.html
Craig Wilson - MCNE, MCSE, CCNA
Novell Support Forums Volunteer Sysop
Novell does not officially monitor these forums.
Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.
"Stephen Driscoll" <[email protected]> wrote in message
news:Jirgk.9735$[email protected]..
> I'm working on a situation which maybe common these days, but I'm looking
> for clarification.
>
> We're using Zen 6.5, users with DLU policies logging into XP clients and
> Nwclient 4.9.1
> We have used DLU to manage local workstation accounts and it works well.
>
> Our XP workstations will be joining a domain soon and our orgranisation
> has many sites.
>
> We think the domain joining will be carried out on a site by site basis.
>
> For users on a site with workstions joined to a domain, they will have the
> Zen DLU policy removed, and login to eDir and the domain using the same
> account....great.
>
> We plan for users without DLU who login to a site with non-domain
> workstation, could choose a location profile that has the NT domain
> field blank (and therfore login local), and login to the workstation using
> a local account pre-setup for them.
>
> But here's the infernal question...
>
> A user WITH DLU login, into a Domain workstation.....This sounds bad!!
>
> How much should I worry about DLU trying to create accounts on a domain
> joined workstation??
> What can I do in that case????
>
> Thanks
>
>

Similar Messages

IPrint secure, DLU and access control

Hi all.
Environment: iPrint 4.20, Novell client 4.91SP1 with pathces, Zen 65SP2
Netware 6.5 SP5 two node cluster.
I just switched to using "high" security for iPrint printers and
immediately stumbled into strange problem.
When I log in as a student (zen 6.5SP2 volatile DLU user) first login
goes fine and novell client passes credentials to iPrint client just
fine. BUT each successive logins with that same account causes printer
login to fail with message "Printer login failed. Do you want to retry".
login also takes very long time to complete. Novell client login goes
thru without problems.
IOW if I do logout-login with same student account printer login fails.
If I login as staff member (no zen DLU) all logins go thru just fine.
I can't see what is wrong in student credentials. If I look at iPrint
settings "passwords"-tab those settings are right.
How to debug what is going on in those failing logins?
Timo Pietil

Jouko Oksanen wrote:
> Timo Pietil wrote:
>> Hi all.
>>
>> Environment: iPrint 4.20, Novell client 4.91SP1 with pathces, Zen
>> 65SP2 Netware 6.5 SP5 two node cluster.
>>
>> I just switched to using "high" security for iPrint printers and
>> immediately stumbled into strange problem.
>>
>> When I log in as a student (zen 6.5SP2 volatile DLU user) first login
>> goes fine and novell client passes credentials to iPrint client just
>> fine. BUT each successive logins with that same account causes printer
>> login to fail with message "Printer login failed. Do you want to
>> retry". login also takes very long time to complete. Novell client
>> login goes thru without problems.
>>
>> IOW if I do logout-login with same student account printer login fails.
>>
>> If I login as staff member (no zen DLU) all logins go thru just fine.
>>
>> I can't see what is wrong in student credentials. If I look at iPrint
>> settings "passwords"-tab those settings are right.
>>
>> How to debug what is going on in those failing logins?
>
> Moi Timo,
>
> Do you mean that the first time when you login as "totally" new (first
> time ever in the pc) DLU user to this workstation everything is ok but
> after second login things start to go wrong?
Yes and no. If I reboot, then login works again just as it should.
> If yes, is there something
> still left behind from volatile user??
hmm... I need to look at that. There shouldn't be of course.
Timo Pietil

Exchange 2003 to GroupWise 7

We are not able to successfully complete a migration of all users from
Exchange 2003 to GroupWise 7 on Netware. Issues below:
** NOT Necessarily in exact order of sequence **
System config:
Netware OES fully service packed, new server, 4GB RAM, 4 Processors.
GroupWise 7.0.1 IR1 Post Office installed. Domain located on an older,
existing server.
Microsoft Windows Server 2003, Exchange 2003 single server. Nothing
special or unusual about this setup for Exchange, pretty generic.
1. Issue attempting to install Migration utility. Utility unable to run
after installation on any workstation. Various errors from "unable to
create GroupWise account" to "unable to login to Exchange mailbox" and a
few others. We also got "fatal errors when trying to extract .csv file".
This was resolved later by running fixmapi.
2. After nearly 18 hours attempting to get the utility to work, we were
able to successfully load it onto 2 workstations. It appeared that it
would work on both.
3. We tried many things to install and run the utility on 15 additional
workstations with no success.
4. Found that the only 2 workstations that appeared to run the utility
were fairly new, less than 2 months old. We then tried fresh installations
of WINXP and WIN2000 on 2 workstations with no success. One of the 2
workstations that did work, later no longer would run the utility. After
running fixmapi.exe on that workstation, it did again work.
5. A suggestion from Novell NTS was to run fixmapi.exe. This appeared to
have corrected 4 of the 10 workstations on which we tried it.
6. Found on 2 workstations that if ZEN DLU (Dynamic Local User) was used,
the migration utility did not work. We found this by logging in as
"Workstation Only" which connected the workstation to the domain, then a
login to eDirectory. The utility did work. So, again we tried to login on
startup to eDirectory and again were not able to run the utility. So, the
fact that some workstations here use DLU may be an issue for this utility.
7. Found that on other workstations, the utility would run ONLY if
"Workstation Only" was selected, then login to eDirectory. We were able to
repeat this sequence multiple times. This is on a workstation not running
ZEN DLU.
8. Of the 6 workstations we were able to run the utility, 1 failed in the
first 5 minutes and would no longer work. So, we split the .csv file from
the Exchange server into 5 parts and started the migration on the 5
available operating workstations. Of the 5, only 2 completed the utility.
Of those 2, only 7 of the 45 users to be migrated completed on 1
workstation and 15 of 45 completed on another.
9. On the 2 workstations that completed, all user accounts were created
but the utility was unable to access the GroupWise account. Login to
GroupWise account failed.
10. Migration utility rules creation issue. There are 2 issues here.
10a. The utility suggests to create a rule using a sub-domain and a
forward rule in Exchange to the new GroupWise system. We are migrating
from: royalmouldings.com to ggc.com. So, the sub-domain is
marexch.ggc.com. The rule would read "forward all mail to
[email protected]. However, Exchange cannot forward to an external
domain at the client level. The only means to do so is to create a contact
in AD with an SMTP email address of the domain to be forwarded to. Then,
in the users account a rule may be created to forward to that newly
created contact. The fact that we are forwarding to an external internet
domain, as in NOT the same one currently used in Exchange, is not
indicated in the documentation. Additionally, if anyone is to do this, a
lot of manual work must be done to accomplish this task. Not too practical
to do for hundreds or thousands of users. This has been a big problem as a
result of the large amount of users in the system and the time it takes to
create each of these contacts.
10b. The second issue is the fact that the rule was created for 1 user,
then no other users had the rule created. So, even if the rule were to
work or we were migrating from and to the same domain name, we'd still
have the rule issue as it was never again created by the utility after the
first user was migrated.
Any help would be greatly appreciated.
Thanks

Bill, you're understandably frustrated. I have a couple of comments.
1. The network authentication system used by Microsoft Exchange requires that you log in to your workstation with the same user ID and password as your account on Exchange. If they don't match, Exchange returns errors that are not always understandable. That might explain why Zen DLU has problems.
2. It seems that every application that deals with e-mail has its own version of MAPI, and they're not always compatible with each other. Outlook, GroupWise, and the migration utility all use MAPI. The fixmapi utility will restore the MAPI DLLs that Outlook expects, which is usually the version that works best.
3. The migration utility should be improved to detect potential errors like these.
>>> Bill Long<[email protected]> 5/19/07 11:59 AM >>>
We are not able to successfully complete a migration of all users from
Exchange 2003 to GroupWise 7 on Netware. Issues below:
** NOT Necessarily in exact order of sequence **
System config:
Netware OES fully service packed, new server, 4GB RAM, 4 Processors.
GroupWise 7.0.1 IR1 Post Office installed. Domain located on an older,
existing server.
Microsoft Windows Server 2003, Exchange 2003 single server. Nothing
special or unusual about this setup for Exchange, pretty generic.
1. Issue attempting to install Migration utility. Utility unable to run
after installation on any workstation. Various errors from "unable to
create GroupWise account" to "unable to login to Exchange mailbox" and a
few others. We also got "fatal errors when trying to extract .csv file".
This was resolved later by running fixmapi.
2. After nearly 18 hours attempting to get the utility to work, we were
able to successfully load it onto 2 workstations. It appeared that it
would work on both.
3. We tried many things to install and run the utility on 15 additional
workstations with no success.
4. Found that the only 2 workstations that appeared to run the utility
were fairly new, less than 2 months old. We then tried fresh installations
of WINXP and WIN2000 on 2 workstations with no success. One of the 2
workstations that did work, later no longer would run the utility. After
running fixmapi.exe on that workstation, it did again work.
5. A suggestion from Novell NTS was to run fixmapi.exe. This appeared to
have corrected 4 of the 10 workstations on which we tried it.
6. Found on 2 workstations that if ZEN DLU (Dynamic Local User) was used,
the migration utility did not work. We found this by logging in as
"Workstation Only" which connected the workstation to the domain, then a
login to eDirectory. The utility did work. So, again we tried to login on
startup to eDirectory and again were not able to run the utility. So, the
fact that some workstations here use DLU may be an issue for this utility.
7. Found that on other workstations, the utility would run ONLY if
"Workstation Only" was selected, then login to eDirectory. We were able to
repeat this sequence multiple times. This is on a workstation not running
ZEN DLU.
8. Of the 6 workstations we were able to run the utility, 1 failed in the
first 5 minutes and would no longer work. So, we split the .csv file from
the Exchange server into 5 parts and started the migration on the 5
available operating workstations. Of the 5, only 2 completed the utility.
Of those 2, only 7 of the 45 users to be migrated completed on 1
workstation and 15 of 45 completed on another.
9. On the 2 workstations that completed, all user accounts were created
but the utility was unable to access the GroupWise account. Login to
GroupWise account failed.
10. Migration utility rules creation issue. There are 2 issues here.
10a. The utility suggests to create a rule using a sub-domain and a
forward rule in Exchange to the new GroupWise system. We are migrating
from: royalmouldings.com to ggc.com. So, the sub-domain is
marexch.ggc.com. The rule would read "forward all mail to
[email protected]. However, Exchange cannot forward to an external
domain at the client level. The only means to do so is to create a contact
in AD with an SMTP email address of the domain to be forwarded to. Then,
in the users account a rule may be created to forward to that newly
created contact. The fact that we are forwarding to an external internet
domain, as in NOT the same one currently used in Exchange, is not
indicated in the documentation. Additionally, if anyone is to do this, a
lot of manual work must be done to accomplish this task. Not too practical
to do for hundreds or thousands of users. This has been a big problem as a
result of the large amount of users in the system and the time it takes to
create each of these contacts.
10b. The second issue is the fact that the rule was created for 1 user,
then no other users had the rule created. So, even if the rule were to
work or we were migrating from and to the same domain name, we'd still
have the rule issue as it was never again created by the utility after the
first user was migrated.
Any help would be greatly appreciated.
Thanks

Terminal server application and contextless login

Hi,
Using zen6.5sp2 here
terminal server application, to a win2k3 with client 4.91sp2 (french +
patch kit c for test)
the credentials are passed correctly from the client to the server, and
the "single-sign-on" works ok only if I specify the context into the client.
I can't get the LDAP contextlogin login to work, neither the old
LgnCLW32.dll
If I do a local authentification, or throught mstsc as usual, it works
it's only via the zenworks apps.
The client 4.91sp1 or sp2 (don't remember) had a bug that it wasn't able
to pass credentials at all, and that's not what I'm looking for...
Any clue ?
Marc

I beleive this is true, but I'm talking about Novell login... What the
SAM has todo with this ???
I do not bother avec Windows login, I have ZEnworks that creates an
account for me...
Steps to replicate the problem:
1) create user1 under context1 into edir
2) create user2 under context2 into edir
3) create zen dlu policies, for loging into a regular winxp, and win2003
terminal server
4) install novell client (configure the location profile with the
treename, and the CONTEXT of CONTEXT1 & configure ldap contextless
login) & zfd on the TS
5) at this point, if anyone uses mstsc.exe to connect to the TS server,
he should be able to login to the TS, with a DLU, and get a desktop
6) create a TS application into ZENworks, which points to the TS, and
start any app (notepad.exe)
7) login into a winxp workstation, with user1, start NAl, click the app,
it should so an "SSO" login to the TS, and start notepad without asking
a password
8) login will FAIL with user2, because he's under context2, and zen
doesn't try todo contextless login
Yeah, I can create alias, but to me, it's not elegant... and a waste of time
Yeah, I can use IDM to create another tree, sync all my accounts into 1
context...
Yeah, I can live with that for the rest of my users under context2....
Marc, just trying to help...
craig wilson wrote:
> All I can tell you is that it is not going to happen.
> Contextless Login is done via the client login utilities.
> These utilities are not involved in the pass-through authentication
> process. It may not even be possible to do.
>
> Through the use of IDM or Lynx this can be completely automated.
> ------------------------------------------------------------------
>
> Create a local account on a workstation and a matching account on a
> Domain with a matching password.
>
> Login locally to the PC and try to access the DC.
> It works.
>
> Try to access a member server to which the domain account has rights.
> It fails and prompts you to enter your user ID. Specify the ID in
> domain/id format and you get in.
>
> Basically a failure of Passthrough authentication because the "Default"
> security container is the local SAM for both systems. One holds the ID
> one does not.
>
> This is really the same basic issue Novell is having via passthrough
> authentication.
>
>
>
>
>
> Marc-Andre Vallee wrote:
>> come on..........
>> RFE....
>

Second Primary Server

Last week I setup a second primary server for redundancy. Everything seemed to work well so I left it alone for several days so everything could sync up. I started getting calls that Vista / 7 logins were very slow, users would press CTRL-ALT-DEL to login and get a blank screen for a few mins before logging in. Once logged in life was good. I checked DNS and everything looked OK both ways. I removed Zen from that server and had a lab of 40 machines refresh then reboot. The problem was gone. Any thoughts on what could cause this?
It's Zen 10.3.3 on a 2008R2 server (both were)
MSSQL 2005 Enterprise for the DB
Thanks for any input!

Thanks for getting back to me guys. It was just a plain install of Zen selecting an exsisting domain and running through the wizard. It placed the server in the servers list in the configuration console. I did not notice if it was hammering the SQL server or not - however about 1/2 of the machines were working perfectly. Would there be any logs I can check anywhere?
Thanks again!
Originally Posted by craig_wilson
Did you change any Closest Server Rules to place this Server 1st in the
list? If so, then it could have been the issue below. If not, I would
suspect that most devices were not even hitting this server. I would
wonder if somehow the 2nd server hitting the DB very hard for some
reasons and causing DB performance issues.
Did you install ZRS or something else on that server?
On 2/1/2012 5:46 AM, nop1983 wrote:
>
> Is it just ZENworks that's slow to login?
>
> Could be a problem with the new server not able to make the
> authenticate request or something like that.
>
> ddevore9;2172176 Wrote:
>> Last week I setup a second primary server for redundancy. Everything
>> seemed to work well so I left it alone for several days so everything
>> could sync up. I started getting calls that Vista / 7 logins were very
>> slow, users would press CTRL-ALT-DEL to login and get a blank screen for
>> a few mins before logging in. Once logged in life was good. I checked
>> DNS and everything looked OK both ways. I removed Zen from that server
>> and had a lab of 40 machines refresh then reboot. The problem was gone.
>> Any thoughts on what could cause this?
>>
>> It's Zen 10.3.3 on a 2008R2 server (both were)
>> MSSQL 2005 Enterprise for the DB
>>
>> Thanks for any input!
>
>
Craig Wilson - MCNE, MCSE, CCNA
Novell Knowledge Partner
Novell does not officially monitor these forums.
Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

Zen 3.2 DLU and Local profiles

We're a high school and DLU has been great in the labs, because we don't
want students to alter any local settings such as wallpaper, etc. Works
great. For teachers and staff, I have begun disabling workstation manager
and setting them up with a static local account so they can have more
flexibility in their local settings. I don't want to do anything with
roaming profiles. Is there a way to setup workstation manager (in Zen 3.2)
to basically create a NON-volatile local user the first time through, and
then to authenticate through and manage that account going forward? Is it
just a matter of checking "Manage existing account" and unchecking
"volatile user" in the user package??
Thanks - Eric

Yes but..............
Any existing Volatile DLU accounts will remain volatile.
The Volatile/Non-Volatile nature of an account is determined upon creation.
[email protected] wrote:
> We're a high school and DLU has been great in the labs, because we don't
> want students to alter any local settings such as wallpaper, etc. Works
> great. For teachers and staff, I have begun disabling workstation manager
> and setting them up with a static local account so they can have more
> flexibility in their local settings. I don't want to do anything with
> roaming profiles. Is there a way to setup workstation manager (in Zen 3.2)
> to basically create a NON-volatile local user the first time through, and
> then to authenticate through and manage that account going forward? Is it
> just a matter of checking "Manage existing account" and unchecking
> "volatile user" in the user package??
> Thanks - Eric

DLU with Windows 2003 server

I am going to be blustery only to provide you with the most info as
possible.
I have setup a Windows 2003 server for terminal services. Installed the
latest Novell Client 4.9 sp2, nici, nmas. I installed the latest
zfdagent.msi from zfd4.01.ir7.
The setup is similar to any WindowsXP machine and I have done this a
thousand times. I have verified that the DLU policy set for the container
includes a DLU for Windows 2000 and Windows 2000 Terminal Services. Okay I
should be able to login and have zenworks create a local users acount but
it does not.
Here are the differences that may effect the proper operation of desktop
management:
a. I have this terminal server setup as a member server in our AD domain -
only to connect to the TS License Manager.
b. I have setup the Netware client location policy | login profile |
Windows Tab | to login in to the local Win2k3 server NOT the domain - and
of course the username field is empty.
c. Then I install the ZfdAgent.msi - when the intsaller gets to the
MiddleTier section - I usally click next and ignore this area, however
this time around the installer will not continue unless I enter an IP
address into the Middle Tier server field.
Other than the above - fairly standard install.
Any help appreciated.
Regards
Ross.

> I have setup a Windows 2003 server for terminal services. Installed the
> latest Novell Client 4.9 sp2, nici, nmas. I installed the latest
> zfdagent.msi from zfd4.01.ir7.
Windows 2003 is not supported with ZfD4.x.
You must use at least the Agent from Zen 6.5.
Regards
Rolf Lidvall
Swedish Radio (Ltd)

Multiple Mail Domains with multiple IP addresses

Hello,
I am attempting to configure a mail server with 3 domains and 3 distinct IP addresses. I am currently only working with 2 of the domains.
Mail sent to either domain is received by the accounts in both domains: if I send a message to [email protected], it goes to both that mailbox and the [email protected] mailbox. I have user accounts set up in WGM for both domains.
I'm sure I have something misconfigured, but the only instructions I can find for multiple domains assume virtual domains using only one IP address.
postconf -n
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debugpeerlevel = 2
enableserveroptions = yes
html_directory = no
inet_interfaces = all
localrecipientmaps = proxy:unix:passwd.byname $alias_maps
luser_relay =
mail_owner = postfix
mailboxsizelimit = 0
mailbox_transport = cyrus
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
mapsrbldomains =
mydestination = $myhostname,localhost.$mydomain,localhost,mail.tomsheehan.com,tomsheehan.com,ma il.19north.com,19north.com
mydomain = tomsheehan.com
mydomain_fallback = localhost
myhostname = mail.tomsheehan.com
mynetworks = 127.0.0.1/32,66.216.189.129/32,66.216.189.133/32,66.216.189.134/32,tomsheehan.c om
mynetworks_style = host
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpdclientrestrictions = permit_mynetworks rejectrblclient zen.spamhaus.org permit
smtpdpw_server_securityoptions = login
smtpdrecipientrestrictions = permitsasl_authenticated,permit_mynetworks,reject_unauthdestination,permit
smtpdsasl_authenable = yes
smtpdtls_keyfile =
smtpduse_pwserver = yes
unknownlocal_recipient_rejectcode = 550
virtualmailboxdomains =
virtual_transport = virtual
Thanks in advance for any help I may receive!
Scott
iMac Core2Duo 2 GHz, iMac G4 700, iMac G4 800, iBook G3 900 Mac OS X (10.4.9)

Scott,
can you elaborate a bit on the final goal?
There is no need to use multiple IPs to run seperate domains. Virtual domains can handle this just fine.
You could run three different instances of postfix bound to different IPs and different configurations. (postfix -c configdir_touse start) Each config directory would have its own main.cf with the main parameters to be changed being "inet_interfaces", "myhostname" and "mydomains". However, unless you have a very specific need this is just an extra headache.
Alex

10.5.2 Virtual Domains - 2 user questions

(NOTE: Generic host and domain names used in this mail, real ones are used for the actual machine)
Clean 10.5.1 install, immediately hit software update multiple times till 10.5.2 and any other offered updates were installed.
Went into WGM and created the accounts for my virtual domain users (I will not be doing any mail accounts on the main server which is called localhost.local) using the same setup as the 10.5.1 tutorial referenced many times on this site. I made no by-hand file changes other than making the bounces soft instead of hard, as I think that virtual domains are supposed to work now with 10.5.2.
Went into Server Admin, added Mail as a service and configured it with my virtual domain in the Advanced/Hosting tab and turned on debug output for SMTP and POP.
Pointed my firewall at the new mail server so that DNS would be correct
Tried sending a mail from my test user to my test user from a mail client on my LAN.
YAY! It works!
Ok, so with the WGM version of virtual domains, where do I put the dreaded catch-all user for the one domain that required it?
Do I just make a virtual user account with the second shortname being @mydomain1.com?
And, for forward-only mail addresses do I make a virtual user account with the "mail" tab set to forward?
Or, do I still use the tutorial method for those features where I edit files directly?
Thanks, and (fingers crossed) last question for a while.
------ main.cf ------
queue_directory = /private/var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = _postfix
unknown_local_recipient_reject_code = 450
unknown_virtual_alias_reject_code = 450
unknown_virtual_mailbox_reject_code = 450
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = _postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/examples
readme_directory = /usr/share/doc/postfix
mydomain_fallback = localhost
message_size_limit = 10485760
myhostname = localhost.local
mailbox_transport = cyrus
mailbox_size_limit = 0
mydomain = local
enable_server_options = yes
inet_interfaces = all
smtpd_client_restrictions = permit_mynetworks reject_rbl_client zen.spamhaus.org permit
maps_rbl_domains =
content_filter = smtp-amavis:[127.0.0.1]:10024
smtpd_sasl_auth_enable = yes
smtpd_use_pw_server = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,permit
smtpd_pw_server_security_options = cram-md5
virtual_transport = lmtp:unix:/var/imap/socket/lmtp
virtual_mailbox_domains = hash:/etc/postfix/virtual_domains
---------- virtual --------
This file is empty other than comments
----------- virtual_domains ----------
mydomain1.com allow
mydoamin2.net allow

Thanks for the feedback. Good to hear virtual domains set up from scratch work in 10.5.2.
Ok, so with the WGM version of virtual domains, where do I put the dreaded catch-all user for the
one domain that required it?
Do I just make a virtual user account with the second shortname being @mydomain1.com?
To be honest, I never tried, but I seriously doubt this will work (worth trying though). I'd put it in /etc/postfix/virtual (can coexist fine with WGM, but you'll need to add the reference to it to main.cf
And, for forward-only mail addresses do I make a virtual user account with the "mail" tab set to forward?
As above, worth trying. Doubt it'll work through WGM.
Generally speaking and from my experience and assuming there are no bugs, Server Admin and WGM allow for basic setups. Anything slightly advanced is better done through the command line. Sad but true.

ZEN Agent install without admin rights

Hi all,
Sorry to re-visit something I've seen a number of posts on, but I can't
seem to get things to work as I've been lead to believe they should. We
have a handful of systems that do not have any instance of the ZEN agent
installed, a mix of NT and XP (odd, I know). We are attempting to create
an automated process that will establish whether the agent is on the
system and if it is not, install it. Seems pretty straight forward and
I've been referencing the following suggestions. There are a number of
posts in the forums as well, but these were the most relevant.
http://www.novell.com/coolsolutions/trench/3490.html
http://support.novell.com/cgi-bin/se...?/10085696.htm
http://www.novell.com/coolsolutions/trench/3383.html
http://support.novell.com/cgi-bin/se...?/10073212.htm
The problem is, despite what these instructions say, we cannot install the
agent without having local admin rights. All the batch files are in
place, and work, but ultimately the install fails. I've seen work arounds
for any OS later than NT, but its important that every system have the
agent.
I've tried almost everything suggested in the links above but I am
primarily pursuing the batch file approach as detailed in...
http://support.novell.com/cgi-bin/se...?/10085696.htm
At what point are rights elevated such that the install can complete in an
NT environment?
I am sure I'm forgetting some relevant details, so humor me please.
Thanks in advance.
Mike

I forgot that RunAs does not come with NT. ( It's available as an add-on,
but even that needs admin rights to install.)
Try PSExec from http://www.sysinternals.com, but I believe that will not
work either, but worth a shot.
Another outside shot is to push the "AlwaysInstallElevated" MSI installer
registry keys via a batch file.
Unfortunately, I doubt your logged on user has the rights to do this
either..............
You may be stuck manually visiting and installing manually.
Craig Wilson
Novell Product Support Forum Sysop
Master CNE, MCSE 2003, CCNA
Editor - http://www.ithowto.com
(Seeking Full-Time Expert? Drop me a note :> )
<[email protected]> wrote in message
news:[email protected]...
> There's no domain to work with. The only admin account available is on
> the local PC. I've seen options using Runas or even CPAU.exe but neither
> are available with Windows NT.
>
> We are copying the relevant files to a directory on the PC before
> beginning the install. To this point, network access has not been an
> issue.
>
> The batch file dictates the install run in the background so I don't see
> it happening, but the problem seems to come down to not having
> administrative rights on the PC. If I launch the .MSI manually it gives
> me an error referencing rights. If I'm logged on as an administrator the
> install completes exactly as it should.
>
> Thanks for the reply. I look forward to any suggestions you may have.
>
>
>> There are lots of scripts, but you need to have some ID that is a local
>> admin. ( If the PC is on a Domain, then a Domain Admin account works
>> great.)
>> Additionally, network access may be lost when running this script, so
>> copying the agent local before the install may help.
>>
>> Where do you hit a snag? Starting the install as the alernate user?
>> Finding an Admin account? Determining if the agent is installed?
>>
>> --
>> Craig Wilson
>> Novell Product Support Forum Sysop
>> Master CNE, MCSE 2003, CCNA
>>
>> Editor - http://www.ithowto.com
>>
>> (Seeking Full-Time Expert? Drop me a note :> )
>>
>>
>> <[email protected]> wrote in message
>> news:[email protected]...
>> > Hi all,
>> >
>> > Sorry to re-visit something I've seen a number of posts on, but I can't
>> > seem to get things to work as I've been lead to believe they should.
> We
>> > have a handful of systems that do not have any instance of the ZEN
> agent
>> > installed, a mix of NT and XP (odd, I know). We are attempting to
> create
>> > an automated process that will establish whether the agent is on the
>> > system and if it is not, install it. Seems pretty straight forward and
>> > I've been referencing the following suggestions. There are a number of
>> > posts in the forums as well, but these were the most relevant.
>> >
>> > http://www.novell.com/coolsolutions/trench/3490.html
>> > http://support.novell.com/cgi-bin/se...?/10085696.htm
>> > http://www.novell.com/coolsolutions/trench/3383.html
>> > http://support.novell.com/cgi-bin/se...?/10073212.htm
>> >
>> > The problem is, despite what these instructions say, we cannot install
> the
>> > agent without having local admin rights. All the batch files are in
>> > place, and work, but ultimately the install fails. I've seen work
> arounds
>> > for any OS later than NT, but its important that every system have the
>> > agent.
>> >
>> > I've tried almost everything suggested in the links above but I am
>> > primarily pursuing the batch file approach as detailed in...
>> > http://support.novell.com/cgi-bin/se...?/10085696.htm
>> >
>> > At what point are rights elevated such that the install can complete
> in an
>> > NT environment?
>> >
>> > I am sure I'm forgetting some relevant details, so humor me please.
>> > Thanks in advance.
>> >
>> > Mike
>>
>>
>

Strange ZEN logout event triggering

Strange ZEN logout event triggering
Hi!
ZCM 10.3.2, Windows XP/7, Novell Client installed, have a bundle associated to device and should be triggered at ZENworks logout. This all seems to work ok, in ordinary way. But, when user auth is ok with Novell Client (against eDir), but is not attached with DLU via ZEN and appear Windows Workstation login screen and user cancel this dialog and return to Novell Client login screen, then before mentioned bundle is triggered, in some unknown for me reason. Because there is no ZEN login, not speaking about logout. I have similar bundle set to trigger at user login ... it does not run same way. Also, don't see same behavior when bundle is set to run at user logout.
Any ideas?
Btw. this kind of cancelling login is seems to related to getting a'lot of Bundle.ItemCreationError's described in http://forums.novell.com/novell-prod...ionerrors.html.
More thanks, Alar.

Originally Posted by NovAlf
Strange ZEN logout event triggering
Hi!
ZCM 10.3.2, Windows XP/7, Novell Client installed, have a bundle associated to device and should be triggered at ZENworks logout. This all seems to work ok, in ordinary way. But, when user auth is ok with Novell Client (against eDir), but is not attached with DLU via ZEN and appear Windows Workstation login screen and user cancel this dialog and return to Novell Client login screen, then before mentioned bundle is triggered, in some unknown for me reason. Because there is no ZEN login, not speaking about logout. I have similar bundle set to trigger at user login ... it does not run same way. Also, don't see same behavior when bundle is set to run at user logout.
Any ideas?
Btw. this kind of cancelling login is seems to related to getting a'lot of Bundle.ItemCreationError's described in http://forums.novell.com/novell-prod...ionerrors.html.
More thanks, Alar.
Hi Alar,
Do you have any update on you problem because I have the same issue and I am wondering if you found any way to bypass it??
I found another thread but no solution:
http://forums.novell.com/novell/nove...ter-login.html
Thank you in advance for your answer,
OAKFND
PS: Zen version is 11.1

DLU policy not applying - Console One won't OK

I've created a DLU policy that has administrator group rights. When I try
to associate it to a user I click OK and the the screen stays (doesn't
close). The button isn't greyed out and an hour glass appears but it does
nothing. I've tried the reverse - associating the policy from the user -
with the same results. Tried deleting and recreating both the user and
policy in different containers.
Dsrepair shows everything is clean and the tree is synced.
Single server tree, netware 5.2 sp7, zen 3.2, console one 3.5
I have other trees exactly the same and do not have this issue....

Don't really want to apply anymore patches. We did on one install and it
messed up all our configurations. This is at a school and with the
students now back I can't afford any down time.
> Hi
> Could you try with Zen SP3 on the current 1.3.6c Consoleone if you see
> the same problem ?
>
> --
> Regards, Kai Reichert
> Novell Support Forum Sysop
>
> People who claim that computers will make life easier for us have
> obviously never used one.

Forest trust unable to find Active Directory Domain Controller

I have two domains with a two-way forest trust. We'll call them ForestA and ForestB. They're on seperate subnets. ForestA's DCs are in one physical location. ForestB's DCs are in two locations, one of which is shared with A.
I'm unable to route traffic directly from the remote DC in ForestB to the subnet ForestA is on, so I created a new DC in ForestA that sits on the subnet ForestB uses (basically, I can't route between subnets via the wireless bridge between locations, but
can within the same location).
I found this: http://www.neomagick.net/zen/2008/11/30/using-dns-to-force-a-domain-trust-through-a-specific-domain-controller-dc/
I followed the instructions to set the new DC in forest A to be the only one the remote DC in forest B was aware of.
Nslookup ForestA.com resolves correctly to this DC, but I'm unable to validate the trust relationship, getting the error:
"Windows cannot find an Active Directory Domain Controller for the ForestA.com domain. Verify that an AD DC is available and then try again."
I'd appreciate any help.

In the event viewer, have you found any event id's that corrospond with this error? Have you ensured all ports required are open? Windows firewall is correctly setup? NIC is properly configured?
Statement below taken from: http://technet.microsoft.com/en-us/library/cc961803.aspx
If you receive the following error, ERROR_NO_LOGON_SERVERS while using the Nltest tool to query the secure channel, this is usually indicative of the inability to find a domain controller for that domain. Run nltest /dsgetdc: < DomainName > : to verify
whether you can locate a domain controller. If you are unable to find a domain controller examine DNS registrations and network connectivity.
ADDS Ports:
http://msdn.microsoft.com/en-us/library/dd772723(v=ws.10).aspx

ZCM DLU Policy Not Applying To Win7 Computer

I am running ZCM v10.3 and am preparing to migrate over to Active Directory. When I first setup ZCM, I created a DLU policy for my Windows 7 computers and its been working fine. However, its time to join my Windows 7 computers (running ZCM v10.3) to the AD Domain and I need to disable the DLU for the machines prior to joining the domain.
To do this I tried to exclude my test workstations from the DLU by adding the workstations to the exclusion list for the DLU Policy. My DLU policy is assigned to my Users so I used the "Excluded Workstation List" to attempt to prevent the DLU from applying to the workstation. This didn't work. I also tried the reverse by applying the DLU to the test workstation and adding users to the Exclusion list, but that didn't work either. I updated the version, ran "zac cc" and ran "zac ref bypasscache" but it didnt work.
I reassigned the DLU to all my Users and tried to use the registry to check for the existence and value of hklm\software\novell\zcm\zenlgn\domainlogin=1, but that didnt work either. I updated the version, ran "zac cc" and ran "zac ref bypasscache" but it didnt work.
Actually, the registry keys (DomainLogin and eDIRLogin) didn't exist so i had to manually add it using an AD GPO. I added DomainLogin and eDIRLogin and assign hexadecimal value of 1 to each DWORD via GPO (FYI). At this point I'm not even sure if the values of these keys are supposed to be set automatically upon login or if the admins manually control the values. Its not clear to me from the documentation on the Novell site. (http://www.novell.com/documentation/...stem_admin.pdf, pg 274)
(DLU Policy Filters not working)
I turned on debug by issuing the command: "zac log level debug", and would've attached the log here, but I don't know how. If anyone needs to see the log, please send me a link on how to attach a log and I'll do so.
I've tried so many different settings and combinations but i'm still unable to get consistent results. At some point I was able to get the DLU Policy to show up in the ZCM Agent properties with the status of "Not Applied" or "Not Effective" or something to that effect. That was the first time I was able to log in without the DLU applying. However it wasn't consistent among other machines so i kept testing. As it stands now, I have removed any filters and exclusions and now my test machine is not receiving any DLU policy and it should because I assigned the DLU Policy to my entire user base. I am totally lost.
Any help is appreciated.

wanman,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your problem been resolved? If not, you might try one of the following options:
- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your Novell Product Support Forums Team
http://forums.novell.com/

601 errors when working with DLU

Hey all,
I've been running into issues at a single site in a WAN-connected school
district.
We have 1 tree with eDirectory 8.7.3.7 on all servers and no errors via
the health checks, DSREPAIR, etc.
The bottom line is this:
If I make a new administrator policy package and enable DLU (under the
XP policy section) and hit the Properties button, I get the error shown
in my screenshot here:
http://www.bndservices.com/novell/dlu1.jpg
Now this only happens with ZENworks which is why I posted it here
instead of the eDirectory forums. I can post there if it's recommended
instead of here but wanted to ask you guys first. Version of ZEN is 6.5.
I have deleted the policy, recreated, used DSBROWSE -A to remove all old
entries of the policy... (as I noticed it was left behind on a few
occasions, even with plenty of time to be cleaned up on its own) This is
the only site this happens at right now.
We had one problem with this school in the past where Novell said there
was an eDirectory problem and had to come in with their programmers
remotely to fix the issue. I can't help but think it could be a similar
situation, but we'll see.
Thanks for any thoughts on this.
Brian

I was thinking it could be a timing issue, which is kind of what you
seem to be describing. Object gets created and then is available for
editing right away, but errors because it's "not quite all there yet"...
I do not have file caching enabled on the client. In the past I would
have thought it was possible, but I make silent installers and package
them into single-stand-alone executables.
The zen agent and client32 ones are quite handy. Get the PC up and
running and then 2 single EXE files install the client and zen agent
from my USB drive (with reboots in between, of course)
I use the acu and install all my switches and options via the
unattend.txt file so I know I won't accidentally forget a setting as
important as file caching...like i used to :P
Marcus Breiden wrote:
> On Tue, 14 Aug 2007 18:44:35 GMT, Brian Binder wrote:
>
>> Thanks - I'll post back if necessary. ;)
>
> good. the problem with the zensnapins is that when you select an option it
> will create a new object and links it directly with the package, sometimes
> the object is created but not there yet.
>
> do you have caching enabled on the client32?

Zen DLU vs AD Domain

Similar Messages

Maybe you are looking for