Local Installation Source - doens't happen

[neo [mvp outlook]]

Comments inline...

Neo,

Thanks for the information but still cannot get the Local Installation
Source to work, the application installs fine though. Please reply as it
seems that you are a little more knowledgeable than the previous post that
just regurgitated Microsoft documentation.

On the machine i'm trying to install Office2003 on all I'm doing is
running
the Setup.exe straight up, no switches. All the switches are comming from
the setup.ini file, is that a problem? When i run the setup I get a
windows
prompt, Open File - Security Warning, I select Run and the installation
goes
forward fine.

Nope. All the options in setup.ini is fine for those that don't like typing
lengthy command line arguements.

It is also normal to get the security warning dialog under XP SP2 and newer
operating system. That is the AES working to protect users. Since we are
troubleshooting, you can disable it temporarily by using the environment
variable mentioned in http://support.microsoft.com/?id=889815

I checked my MST file and the only options I selected as they relate to
Local Installation Source is Step 8 of 24 in the MS Office Custom
Installation Wizard, Configure Local Installation Source, I set it to
Configure Local Installation Source - Product Key / Accept terms of
license
agreement.

These are my settings in the setup.ini file
CDCACHE=2
LOCALCACHEDRIVE=D
DELETABLECACHE=0
PURGE=0

One funny thing i see is the LOCALCACHEDRIVE setting, the original .ini
file
says LOCALCACHEDRIVE=c:\ but it's commented out with preceding
semicolon.
Does it have to be written as C or does it need to be C:\ , in your post
you wrote just a C. I've tried it both ways with the same result of no
local
installation source...

Never tried a setup with "C:" or "C:\". It just worked straight out of the
box with "C".

Based on the above and below, what are the NTFS permissions on D:\?

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[RayT]

Neo,

Thanks for your effort and help in trying to figure out my problem,
unfortunately I’ve spent allot of time testing in order to figure out why I
couldn't get the Local Source Caching to work.

Apparently you cannot use an IP address to get to the share to run the
setup; you must use a computer name.
_________________________________________
Setup for my Tests:
I created a share on the network drive and copied the entire CD to this
network share; all files untouched and not modified at all.
_________________________________________

Test 1
From the client computer’s RUN window I typed in \\192.168.1.1\ShareName
-When the folder is displayed i double clicked the setup. The result was the
application installed properly but no Local Installation Source was created
and there is an error at the end of the log file that says:

Using Office Source Engine at path:
\\192.168.1.1\Office2003Pro\FILES\SETUP\OSE.EXE
Successfully started Office Source Engine in stand-alone mode.
Reading from "\\192.168.1.1\Office2003Pro\FILES\SETUP\SETUP.INI":
"Cache\LocalCacheDrive" (Default: )
Value: C:\
Failed to download file: DW20.ADM_1033.
Error 0x8007000f
Failed to download file.
Retrying error for resource: DW20.ADM_1033
Download retry 0 failed: 0x8007000f
Download retry 1 failed: 0x8007000f
Download retry 2 failed: 0x8007000f
Error 0x8007000f
failed to wait for file
Couldn't perform local caching.

_________________________________________

Test 2
From the client computer’s RUN window I typed in \\ServerName\ShareName
-When the folder is displayed I double clicked the setup. The result was the
application installed properly and the Local Installation Source was created
perfectly...

Microsoft needs to include this in their documentation, do not \\ to and IP
address when running the install...

Thanks again Neo, let me know what you think about this one….

Ray

_________________________________________

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[neo [mvp outlook]]

I don't think it is a bug, but more along the line of AES getting in the
way. The reason I suspect this is the way Microsoft treats host names with
dots. In this case, what you and I see as a local IP address is actually
being treated like a big ol' nasty host located on the world wide web. You
can see this behavior if you use IE and access internal websites. (e.g.
http://192.168.1.1 would be seen in the "Internet Zone" while http://server
would not.) Easiest way to verify is to drop back to anything pre service
pack 2 for XP and see if the install still fails.

In any event, thank for reporting back that you where getting bit by using
an IP address. I'll file this away for future use since I can see some
using fully qualified server names to access software deployment sharepoints
and what failures could arise from it.

 

[RayT]

Neo,

I suspected maybe something in XP SP2 causing this interference as well,
have not tested my theory with a Pre-SP2 OS. I knew the fix would be
something so simple, definately one for you, and microsoft, to file away. I
may build a VMware virtual machine with Windows XP straight up today to test
the theory if i have time, i'll let you know if i do.

Thanks again for your effort...

Ray

 

[RayT]

Neo,

I suspected maybe something in XP SP2 causing this interference as well,
have not tested my theory with a Pre-SP2 OS. I knew the fix would be
something so simple, definately one for you, and microsoft, to file away. I
may build a VMware virtual machine with Windows XP straight up today to test
the theory if i have time, i'll let you know if i do.

Thanks again for your effort...

Ray

 

[RayT]

Neo,

I suspected maybe something in XP SP2 causing this interference as well,
have not tested my theory with a Pre-SP2 OS. I knew the fix would be
something so simple, definately one for you, and microsoft, to file away. I
may build a VMware virtual machine with Windows XP straight up today to test
the theory if i have time, i'll let you know if i do.

Thanks again for your effort...

Ray