VMware Horizon Community
vyper
Contributor
Contributor

VDI & Novell

Hi all,

I am setting up a VDI enviornment for a client who uses Novell eDIrectory. I have all the backend setup with a NLB clusterd VDM broker service etc. I am in the process of creating the Gold Template for the desktops. I run through the standard sysprep customization in VC and the sysprep won't take place until i log on manually to the desktop. This is because the Novell Client is installed and taken control of the login process. Has anyone seen this or got a suggestion to work around ??

Thanks

0 Kudos
25 Replies
TomHowarth
Leadership
Leadership

try changing the GINA string to move the Novel gina lower down the chain

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
jdiekert
Contributor
Contributor

hi,

you can also install the Novell Client during the sysprep-process using the RunOnce Section

0 Kudos
vyper
Contributor
Contributor

I am continuing to work on this and am getting errors during the sysprep. When the sysprep starts it fails with what apears to be the password reset. I have changed the image to have a blank password. It keeps complaining about unable to change registry etc.....

0 Kudos
MAHC
Enthusiast
Enthusiast

I had a similar problem but with mine I forgot what user I logged in as and found that I had no rights to the device and when I changed to admin and ran sysprep it worked fine.

0 Kudos
admin
Immortal
Immortal

Should work with the Novell Client version 4.91 sp5: [http://www.novell.com/beta/auth/beta.jsp?id=2825&type=1|blocked::http://www.novell.com/beta/auth/beta.jsp?id=2825&type=1

http://www.novell.com/beta/auth/beta.jsp?id=2825&type=1]

and a Reg key change of:

(HKLM\SOFTWARE\Novell\Login) TSClientAutoAdminLogon (1) DefaultLocationProfile

(Default)

Thanks,

Christoph

0 Kudos
vranishm
Contributor
Contributor

We spent weeks with VmWare engineers and consultants trying to get VDM to work with Novell Client because we were using the LeoStream connection broker and it was too expensive and unreliable . We then decided to put everyone in AD synchronizing their accounts using identity manager, which is included with most Netware licenses. We then enabled CIFS on our Netware server for seamless file share access and a middle tier server for Zenworks access.

0 Kudos
csd440
Contributor
Contributor

I am demoing VMware VIew in an eDirectory environment, and it is working very well. The view server, and virtual server sit in a small AD since vmware view requires it for composer to work with VC. The workstations that I created to use composer with is not in AD, but it has ZenWorks installed on it. I am using the Dynamic local user policy in ZenWorks to allow users to login to these workstations. The issue is that each userID must exist in the small AD. I am doing this with IDM as well in order to keep the passwords for the view client the same as the novell user id and password. This allows the users to login to view and the workstation with the same user ID. VMWare needs to get off the Active Directory dependency and make the new stuff work with LDAP out of the box. I have heard that Virtual Center will run on Linux and work with LDAP in the near future, so that should pave the way for all the other products to start working the same. eDirectory and LDAP is not a hard thing to integrate with, and with Novell being a partner, why not integrate with eDirectory or atleast LDAP. The more stuff that works with LDAP the more I can fight the need to bring AD into our environment.

0 Kudos
jmacdaddy
Enthusiast
Enthusiast

Try turning off the UNC Patch Filter in the Advanced Settings of the Netware Client on your Gold Template. If you need that to be enabled after your VM's are burned from the template, just enable the setting using a Group Policy that has the Netware 4.9x ADM loaded on it.

0 Kudos
csd440
Contributor
Contributor

I finally got this whole thing working in a Novell Environment thanks to OES2sp1. I installed DSFW that comes with OES2sp1, this is domain services for windows. It will basically map a container that is partitioned to an OES2sp1 server and allow windows to think eDirectory is AD. This worked better than I imagined. I was able to join VC, and the view server to my eDirectory AD domain. When I got to add users and groups it see's my eDirectory environment and allows me to add eDir user objects and group objects as if they where AD users and groups. I am also suprised but authentication into eDirectory via DSFW is quicker than the AD we have hear. I plan on testing this to death for the next six month, and if all goes well we will run AD on eDirectory and be able to utilize Novell and Windows together very closely to include projects like Vmware View.

Post if you have questions.

0 Kudos
olivier_dubroca
Contributor
Contributor

I'm using leostream too. I spend lot of time on the sso login process .... argh ....

Is there any solution for vdi in Novell environment with no AD ?

0 Kudos
harewego1
Contributor
Contributor

This is a rough doc detailing my POC VMView/ VDI in an A.D / eDir mixed environment. I was able to complete a working persistent VM connection. (With some minor issues)

All VM user accounts in eDir were defined through IDM into A.D. I used A.D. groups w/GPO to manage access to VMV Pools.

I created two types of GOLD images. Both contained the NetWare Client 4.91 sp5 preinstalled.

Settings on the client should be:

- Must have LDap enabled.

- Within the client settings, the following changes were set:

Advance Login:

Login without Novell’s GINA: On

LDap contextless Login

Enable LDap Treeless login

Enable LDap context search scope

Ensure the following registry entry is set after you have installed the VMView Agent on the master image:

"C:\Program Files\VMware\VMware View\Agent\bin\wsgina.dll"=string:GINADLL

You should now be able to authenticate the VM via a normal Windows domain login that should pass your credentials to eDir and authenticate you with your login script. If you authenticate but your log in script fails to run, you can add this entry to your registry:

“nwscript=reg_expand_sz:loginw32.exe %username% /NA /CONT

When you first login, you may receive and Novell Security Message “The system could not log you into the network……”

Click “ok” and proceed to manually add your credentials to finish the login process.

For persistent images, this should be the only time this happens.

For non-persistent VM’s, you will receive this every time you log in.

This is one of my issues.

There are NetWare Client configuration settings that are set the first time a user authenticates to a vm that are written to the users profile. These settings are maintained so when the same user logs on the same vm, the pass-through credentials from your WYSE authentication goes completely through eDirectory with no issues. However, on Non-persistent vm’s, continuously get the “The system could not log you into the network……” error message because there is no profile.

These are the two types of images I created:

“Fat Image”

Standard Windows XP sp2 stations

Single partition (7 -10 gig) – 384 memory

Apps (Java, Acrobat,etc… Pre-installed)

Template: Non-Domain build. Sysprep set to import computer object into specific A.D container. Container associate GPO forces Domain associated groups as members to the Local Remote Desktop Users Group for each VM.

“Thin-Composed Image”

Master Windows XP sp2 Image (10 gig)

Persistent and or Non-Persistent Linked Clones deploy VMs’. (1.5 – 2.0 gig) – 384 Memory

ThinApp (Acrobat, email, etc)

Master Image already defined in Domain. Quickprep used to created Linked Clone objects into specific

OU Containers. Master Image already contains necessary Domain group memberships to the local Remote Desktop Users Group.

You can these additional NetWare Client options for passive mode or place the following registry entries:

URL: http://www.novell.com/documentation/noclienu/noclienu/index.html?page=/documentation/noclienu/noclie...

“PassiveMode”=dword:00000001

“PassiveModeNDSLogin”=dword:00000001 “PassiveModeNDSLoginSilent”=dword:00000000 or 00000001 “PassiveModeNDSLoginRequired”=dword:00000000 or 00000001

Hope this helps. Good Luck

0 Kudos
HHO-Tim
Contributor
Contributor

Hello

i'm trying just a while. It is a nice description from you, but in our environment it doesn't work.

I have created a persistent pool and every time i get the message from the Novell Client “The system could not log you into the network……”.

Then i can write my password in the Novell Gui and everything is fine, but i would like that the user is logged in automatically to netware.

Do you have an idea for me?

Best regards

Tim

0 Kudos
harewego1
Contributor
Contributor

I've ended up with these scenarios'.

On a persistent pool, the first time a user authenticates, they do receive the " “The system could not log you into the network……” error.

If they manually logon to Netware afterwards then logoff the VM, they could then re-connect and the credentials will pass-through correctly.

Theory; When the user first authenticates, Contextless login has not tried to set the users account container so it does not know where to find the ID within the eDir tree. When you manually login the user it finds and sets the correct context, thus every login afterwards would allow the credentials to pass-through.

Other Theory: Since the user is logging on to the VM for the first time, the local Windows profile has yet to have been setup for the authencating account. While the profile is being created, NetWare is tring to authenticate the account but does not have the correct context settings, causing the first login to fail.

If your vm pool is non-persistent, it will happen at every login since no local profile is maintained after logoff.

You can test this theory with a fat system. Reverse the GINA.dll as mentioned previously and try to authenticate a domain user using the Windows login GINA as the primary authentication. Windows will pass these credentials through the NetWare client but should fail as well on the first login since it will not have the correct context set.

A fix could be to ensure all users who will be authenticating to a particular VM pool be located within the same eDirectory context. Then set your template VM by having the NetWare Client configuration settings pre-set the context to the end-users location. This should then automatically pass the credentials without error.

Good Luck.

0 Kudos
HHO-Tim
Contributor
Contributor

Hello harewego1,

i had uninstall the Novell Client 4.91 SP5 and install the Client 4.91 SP4. Then it works.

Best regards

Tim

0 Kudos
harewego1
Contributor
Contributor

Hi Tim,

Very cool that it works. Going to have to go back and research the difference between sp4 and sp5 on the clients. Glad to hear success!

0 Kudos
sysbeheer
Contributor
Contributor

Hi all,

We where working on a solution to get SSO working. you're information got us on the road.

In the end this is how we got it working:

First the installation in the following order:

  • Windows XP SP3 basic installation

  • Netware Client 4.91 SP5 inclusing patches up to 24 march 2009 (typical installation/reboot)

  • ZfDAgent from SP3a-HP3 Zen 7

  • VMware View Agent (default installation inclusing SSO!)

Then make sure following .reg settings are correct or set:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

i. "GinaDLL"=C:\Program Files\VMware\VMware View\Agent\bin\wsgina.dll

ii. "VdmGinaChainDLL"=NWGINA.DLL

Add the following registry keys to:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login

i. DefaultLocationProfile=Default (REG_SZ)

ii. TSClientAutoAdminLogon=1 (REG_SZ)

You can use fixed context or LDAP contextless login if you like. Both work fine in our environment now....

Grx,

Andre van de Werken

System Engineer ASVZ/Carante Groep

0 Kudos
jrainsberger
Contributor
Contributor

How is this setup working for you? I see that it has been over six months have you put the solution into production?

0 Kudos
aengel4111
Contributor
Contributor

Hello,

we are using the dfsw (OES 2 SP2) feature in our enviroment too.

Im building a VMware View 4 enviroment with ESX 4. But I have Problems with the Quick prep Account.

The System tolds me bad username or password when i try to register a user for quickprep. But the credentials

works 100% fine.

Is there a Basic Problem with dfsw and the quick prep feature for view 4.

Can you help me please

Greetings

Andreas

0 Kudos
sysbeheer
Contributor
Contributor

Hi,

Solution is in production now for 4 months and working fine..

if you need more details let me know...

Grx,

André van de Werken

0 Kudos