Installation & Licensing

Reply
*Sandberg, Lars
Message 1 of 5 (146 Views)

MDT R5 & NLS problem error(4)

146 Views, 4 Replies
02-23-2001 08:59 PM
Hi, one of our costumers did by themself following deployment-setup:

PC A:
Running Win NT 4 Workstation (SP5 ??) running the ADLM software from the
MDT R5 CD. It has a fixed IP-address. The deployment image-files on
these PC is configured to do a silent-install on the E drive.

PC B:
New computer only with a C-drive (30 GB), with Windows 2000 Proffesional
SP1 Danish version (absolutely not by my advise)

The 2 PC's is in the same subnet and they can ping each other. Because
of the missing E drive on PC B I did a normaly install of MDT R5. I
could see that adesksys.dll (102.400 bytes, date 18 april 2000) is in
the \MDT5 dir. The ACADSERVER (on PC B) was set to @IP-address of PC A.
I did run winquery on PC B, and detected the running NLS server on PC A
with several licenses free for MDT R5 (the costumer don't have a mixed
CAD environment all licenses is MDT R5). however, when starting MDT I
get an error (4) since it somehow can't find the free licenses. Another
MDT R5 NLS installation on PC C works well.
At this point I didn't install SP2 for MDT R5 (I will wait a week or two
with SP3)
Can anybody come up with a hint?

Best regards Lars
*martin, jason
Message 2 of 5 (146 Views)

Re: MDT R5 & NLS problem error(4)

02-24-2001 05:02 AM in reply to: *Sandberg, Lars
Lars -
I don't know much (pronounced anything) about international versions, but I
do know that on the US versions doing a "local" install (an install directly
from the CD) to try to connect to an adlm server is not supported. Rather
than doing an install from the CD on PC B create a new deployment image with
the install path to C: and just run the deployment.

I also don't think that the acadserver variable should be set to the ip
address of the adlm server. Everything I've seen indicates that the
acadserver variable should be set to the host name of the adlm server. Make
sure that PC B can connect to PC A by host name (not netbios name) and set
the acadserver variable to that. PC A must also be able to connect to PC B
by host name for the adlm to work.

hth

jason martin
frankfurt-short-bruza

Lars Sandberg wrote in message
news:MPG.1501ce7d7610db76989687@discussion.autodesk.com...
> Hi, one of our costumers did by themself following deployment-setup:
>
> PC A:
> Running Win NT 4 Workstation (SP5 ??) running the ADLM software from the
> MDT R5 CD. It has a fixed IP-address. The deployment image-files on
> these PC is configured to do a silent-install on the E drive.
>
> PC B:
> New computer only with a C-drive (30 GB), with Windows 2000 Proffesional
> SP1 Danish version (absolutely not by my advise)
>
> The 2 PC's is in the same subnet and they can ping each other. Because
> of the missing E drive on PC B I did a normaly install of MDT R5. I
> could see that adesksys.dll (102.400 bytes, date 18 april 2000) is in
> the \MDT5 dir. The ACADSERVER (on PC B) was set to @IP-address of PC A.
> I did run winquery on PC B, and detected the running NLS server on PC A
> with several licenses free for MDT R5 (the costumer don't have a mixed
> CAD environment all licenses is MDT R5). however, when starting MDT I
> get an error (4) since it somehow can't find the free licenses. Another
> MDT R5 NLS installation on PC C works well.
> At this point I didn't install SP2 for MDT R5 (I will wait a week or two
> with SP3)
> Can anybody come up with a hint?
>
> Best regards Lars
*Sandberg, Lars
Message 3 of 5 (146 Views)

Re:

02-24-2001 10:52 PM in reply to: *Sandberg, Lars
In article ,
jmartin@^nospam^fsb-ae.com says...
> Lars -
> I don't know much (pronounced anything) about international versions, but I
> do know that on the US versions doing a "local" install (an install directly
> from the CD) to try to connect to an adlm server is not supported. Rather
> than doing an install from the CD on PC B create a new deployment image with
> the install path to C: and just run the deployment.
>
> I also don't think that the acadserver variable should be set to the ip
> address of the adlm server. Everything I've seen indicates that the
> acadserver variable should be set to the host name of the adlm server. Make
> sure that PC B can connect to PC A by host name (not netbios name) and set
> the acadserver variable to that. PC A must also be able to connect to PC B
> by host name for the adlm to work.
>
> hth
>
> jason martin
> frankfurt-short-bruza

Hi Jason

Thanks for your reply. I do have some comments. In the earlier days,
that means MDT R3 & R4, the adesksys.dll was only installed on the
client PC's when using the deployment setup. That means that we had to
copy the adesksys.dll manualy to the \mdt dir when doing a standard
install (non NLS install). I did that many times with succes as well a
using the IP-address (if it's static), because we could prevent
eventually DNS errors regarding the hostname which requires a DNS-look-
up.
The MDT R5 standard install (non NLS install) copies the adesksys.dll to
the MDT dir, but something is missing or what??

Best regards Lars
*martin, jason
Message 4 of 5 (146 Views)

Re:

02-25-2001 10:27 AM in reply to: *Sandberg, Lars
Lars -
My experience is with US versions only so I may not be much help here but...
I've heard of some people getting away with copying adesksys.dll to local
installs and getting it to work with the adlm server but according to
autodesk this is unsupported. If you get it to work, great. If not sorry.
The same is true of any type of installation not created using some type of
deployment method. Creating a second deployment to c: really isn't that big
of a deal. I'd highly recommend uninstalling the "local" install on PC B,
creating a new deployment to the c: drive and installing mdt from the second
deployment.

I know that this isn't the answer that you're looking for, but as far as I
know it's the only way to have a "supported" installation.

hth

jason martin
frankfurt-short-bruza

Lars Sandberg wrote in message
news:MPG.15033a8c45ad62bb989688@discussion.autodesk.com...
(snip)
>
> Hi Jason
>
> Thanks for your reply. I do have some comments. In the earlier days,
> that means MDT R3 & R4, the adesksys.dll was only installed on the
> client PC's when using the deployment setup. That means that we had to
> copy the adesksys.dll manualy to the \mdt dir when doing a standard
> install (non NLS install). I did that many times with succes as well a
> using the IP-address (if it's static), because we could prevent
> eventually DNS errors regarding the hostname which requires a DNS-look-
> up.
> The MDT R5 standard install (non NLS install) copies the adesksys.dll to
> the MDT dir, but something is missing or what??
>
> Best regards Lars
*Sandberg, Lars
Message 5 of 5 (146 Views)

Re:

02-25-2001 04:18 PM in reply to: *Sandberg, Lars
In article <5D71B9B434318055B6BC80E5FF7630D6@in.WebX.maYIadrTaRb>,
jmartin@^nospam^fsb-ae.com says...
> Lars -
> My experience is with US versions only so I may not be much help here but...
> I've heard of some people getting away with copying adesksys.dll to local
> installs and getting it to work with the adlm server but according to
> autodesk this is unsupported. If you get it to work, great. If not sorry.
> The same is true of any type of installation not created using some type of
> deployment method. Creating a second deployment to c: really isn't that big
> of a deal. I'd highly recommend uninstalling the "local" install on PC B,
> creating a new deployment to the c: drive and installing mdt from the second
> deployment.
>
> I know that this isn't the answer that you're looking for, but as far as I
> know it's the only way to have a "supported" installation.
>
> hth
>
> jason martin
> frankfurt-short-bruza
>

Hi Jason

Thanks for your reply, I will try that and let you know the result, by
the end of the week.

Best regards Lars

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Welcome to the new Autodesk Community!
If this is your first visit, click here to get started and make the most of the Community. Let us know what you think of the new experience in the Community Feedback Forum.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community




Connect with Us

Twitter

Pinterest

Blog

Youtube