"My Documents" on a network share -> InstallShield fails with 1327

[Guest]

I have mapped my "My Documents" system directory (or "Documents" as it's
called in Vista) to a subdirectory of a network share permanently connected
to a drive letter.

The problem is that every installation using InstallShield is failing with
the error message: "Error 1327.Invalid Drive U:\"

U: is the letter I'm using for the network share.

The share is working, the network connection is stable, I can browse U:\ and
"My Documents" just fine.

If I'm moving "My Documents" to a local directory, everything is working.
But that's very cumbersome.

I've found a knowledge base entry (282183) which is referring this problem,
but they assume that the network share isn't working properly, which is not
the case for me.

I think that InstallShield might try to access U:\ with different
credentials and doesn't get access because of that. Can that be the problem?
How can I work around this?

 

[Keith Miller MVP]

It may just not like network drives, I'm not sure. But you might try this:

In the Properties dialog for the U: drive, select the 'Security' tab.

Click the 'Advanced' button.

On the 'Permissions' tab, click the 'Edit...' button, then click the
'Add...' button.

For the object name, use:

NT Service\TrustedInstaller

Give TrustedInstaller 'Full Control' permissions.

OK you're way out.

Credit where credit is due -- I learned how to add TrustedInstaller here:
http://blogs.msdn.com/irenak/archive/2007/01/30/sysk-277-how-to-bring-back-the-trustedinstaller.aspx

 

[Guest]

Hello there. I am having the same exact problem as Martin. When I attempt
to add the "NT Service\TrustedInstaller" account to the permissions list, I
am told that this object cannot be found.

This machine is a domain member. Would this matter?

I appreciate the help.

 

[Guest]

Keith,

thanks for your answer, I almost missed it, somehow the notification email
got lost.

I think I might have found the cause of the problem, and I'm pretty sure
that it qualifies as a serious bug in Vista:

If you define a home directory on a network share in the Domain User's
properties, the connection for that share is ONLY recreated in the user
context.

If you open a shell with admin privileges (right-click, "Run as
administrator") and use "net use" to list all connected shares, you'll see
that the share for the home directory is NOT listed. So each process using
the context of the elevated user can't see the connection!

I started to work around this by writing a script which reconnects the
shares for the admin context, but I have to start this script manually after
each login, since it's not possible to auto-run a script with admin rights...

Could you please try to reproduce that problem? If it's not just on my
network, then maybe this should be forwarded to the Vista development team.

 

[Guest]

Keith,

I have troubles with your suggestion. I can only add NT
Service\TrustedInstaller for local objects, but since U:\ is a network share,
I can only add domain objects to it's ACL. I haven't figured out a way to add
the local TrustedInstaller of my machine, and I doubt it's possible.

 

[rpotter28]

Keith,

thanks for your answer, I almost missed it, somehow the notification email
got lost.

I think I might have found the cause of the problem, and I'm pretty sure
that it qualifies as a serious bug inVista:

If you define a home directory on a network share in the Domain User's
properties, the connection for that share is ONLY recreated in the user
context.

If you open a shell with admin privileges (right-click, "Run as
administrator") and use "net use" to list all connected shares, you'll see
that the share for the home directory is NOT listed. So each process using
the context of the elevated user can't see the connection!

I started to work around this by writing a script which reconnects the
shares for the admin context, but I have to start this script manually after
each login, since it's not possible to auto-run a script with admin rights...

Could you please try to reproduce that problem? If it's not just on my
network, then maybe this should be forwarded to theVistadevelopment team.

You are a genius! Thanks for the work around.

 

[Guest]

Same thing here. Anyone ever find a solution for this? As far as rolling
Vista out at my company, this is most definitely a show stopper.

Thanks

 

[Guest]

What is? Stop deleting what you are talking about.

 

[Guest]

It probably would have been easier for you to just ignore my post than to
reply with something completely useless. Did you even read the thread?

Next time, just move along.

 

[Guest]

No I didn't read the thread as some moron deleted it. See look down - can
you see it. I can't. Because a moron came along and deleted it. Not only
that but the moron is still deleting posts. This is normally unethical
behaviour. What fraud are you intending to do here.

As you just did again moron, you keep deleting it. So I suggest you don't
post here as you seem to want secret posts. It is also not done making
disembodied posts about nothingl. It's not rocket science. I realise you are
an idiot but this is a newsgroup not some web page for morons. If you keep
deleting the history then noone will know what you are talking about, idiot.

 

[Guest]

LOL. You're funny.

And yes, I did just do it again.

 

[Guest]

What a wanker, so you know you are deleting your thread but you do it to
spite me. it was your question.

 

[Guest]

OK, let's be friends.

I was just replying to an existing thread and removing all of the extra
history that gets repeated over and over and seems to clutter up the place.
I honestly do not understand why the other 6 posts above mine that contain
the rest of the history can not be seen. I see them fine. Perhaps you are
right. I am a moron and i have no idea how to use simple bulletin board
software. I guess thats my cross to bare.

That being said, here is the history:

I have mapped my "My Documents" system directory (or "Documents" as it's
called in Vista) to a subdirectory of a network share permanently connected
to a drive letter.

The problem is that every installation using InstallShield is failing with
the error message: "Error 1327.Invalid Drive U:\"

U: is the letter I'm using for the network share.

The share is working, the network connection is stable, I can browse U:\ and
"My Documents" just fine.

If I'm moving "My Documents" to a local directory, everything is working.
But that's very cumbersome.

I've found a knowledge base entry (282183) which is referring this problem,
but they assume that the network share isn't working properly, which is not
the case for me.

I think that InstallShield might try to access U:\ with different
credentials and doesn't get access because of that. Can that be the problem?
How can I work around this?

It may just not like network drives, I'm not sure. But you might try this:

In the Properties dialog for the U: drive, select the 'Security' tab.

Click the 'Advanced' button.

On the 'Permissions' tab, click the 'Edit...' button, then click the
'Add...' button.

For the object name, use:

NT Service\TrustedInstaller

Give TrustedInstaller 'Full Control' permissions.

OK you're way out.

Credit where credit is due -- I learned how to add TrustedInstaller here:
http://blogs.msdn.com/irenak/archive/2007/01/30/sysk-277-how-to-bring-back-the-trustedinstaller.aspx


--
Good Luck,

Keith
Microsoft MVP [Windows XP Shell/User]

Hello there. I am having the same exact problem as Martin. When I attempt
to add the "NT Service\TrustedInstaller" account to the permissions list, I
am told that this object cannot be found.

This machine is a domain member. Would this matter?

I appreciate the help.

Keith,

thanks for your answer, I almost missed it, somehow the notification email
got lost.

I think I might have found the cause of the problem, and I'm pretty sure
that it qualifies as a serious bug in Vista:

If you define a home directory on a network share in the Domain User's
properties, the connection for that share is ONLY recreated in the user
context.

If you open a shell with admin privileges (right-click, "Run as
administrator") and use "net use" to list all connected shares, you'll see
that the share for the home directory is NOT listed. So each process using
the context of the elevated user can't see the connection!

I started to work around this by writing a script which reconnects the
shares for the admin context, but I have to start this script manually after
each login, since it's not possible to auto-run a script with admin rights...

Could you please try to reproduce that problem? If it's not just on my
network, then maybe this should be forwarded to the Vista development team.

Keith,

I have troubles with your suggestion. I can only add NT
Service\TrustedInstaller for local objects, but since U:\ is a network share,
I can only add domain objects to it's ACL. I haven't figured out a way to add
the local TrustedInstaller of my machine, and I doubt it's possible.

Same thing here. Anyone ever find a solution for this? As far as rolling
Vista out at my company, this is most definitely a show stopper.

Thanks

There. Thats the history. Now, if you have any idea how to get all of this
working, I would gladly donate my first born moron child to you.

Thanks in advance.
-Chris

 

[Don]

OK, let's be friends.

I was just replying to an existing thread and removing all of the extra
history that gets repeated over and over and seems to clutter up the place.
I honestly do not understand why the other 6 posts above mine that contain
the rest of the history can not be seen. I see them fine...

From your headers:
X-Newsreader: Microsoft CDO for Windows 2000

I've never used 'Collaborative Data Objects' so I don't know how it/they
work, but it appears that it may be suppressing any quoted text that you
include in your reply. I have used newsreaders with that 'feature' and
I turn it off because it appears to have no logical purpose.

 

[Mike Torello]

This is an old thread,

Yeah... TWO YEARS OLD is "old".