What are the common reasons for error 1308?
Question
Are there common reasons for error 1308?
Answer
Generally:
Bad Driver/Device, Bad Media, Bad Package are the most common sources. The most common path to eliminating the driver/device from the equation, is to copy to the local hard drive like the media copy instructions in this KB:
https://support.microsoft.com/?id=307372. I do not know of general techniques to eliminate bad media other than having customers request new media. Bad packages are generally from poor production process and occasionally from incomplete designs.
Other Specific Instances
Consumption Issues
Share CD over Network:
Visual Studio has posted
Visual Studio .NET Readme (Part 2) which says folks sometimes try to share an install over the network
5.2 "Error 1308: Source File Not Found"
<snip>
IMPORTANT: Visual Studio .NET cannot be shared over a network by using a shared CD-ROM drive. For additional information about how to install Visual Studio from a network share, click the article number below to view the article in the Microsoft Knowledge Base:
312779 (https://support.microsoft.com/kb/312779/EN-US/) INFO: Visual Studio .NET Readme (Part 1) ****
Improper Admin Image Manipulation:
Office servicing reports in "Error 1308: Source File Not Found" error message when you update your client computer to Office 2000 SR1/1a a problem with swapping SHORTFILENAMES in the admin image manipulation
The error message appears because the SR-1/SR-1a administrative update was performed without including the SHORTFILENAMES=TRUE command-line property. The Windows Installer (MSIEXEC.EXE) SR-1/SR-1a administrative update process automatically defaults to the long file name configuration, unless the SHORTFILENAMES=TRUE command-line property is used (that is, the default directory name is Program Files instead of PFiles).
The original administrative installation was created using Setup.exe /a, which defaults to short file names for backward compatibility; therefore, the update to Microsoft Office 2000 SR-1/1a also needs to include short file names. If the SHORTFILENAMES=TRUE switch is not used when the update to the administrative installation point is performed, the updated files are moved and installed into new long file name directories, and the original files in the short file name directories are not updated. Because the original installation of Office 2000 was performed from the short file name directories, the client update process tries and fails to locate the SR-1 updates in the short file name directories.
Improper Use of HTTP Location
:
Office servicing reports in
You receive an error message when you try to use a Radia Application Manager transform file to install Office 2003 on a Windows 2000 Professional-based computer support a problem with trying to retrofit http into a package that does not support it
Microsoft does not support the installation of Office 2003 from an HTTP location. Additionally, Microsoft does not support the use of third-party vendor customizations or utilities for the installation of Microsoft Office products.
Exchange reports an instance of the above
FIX: Error 1308 When You Install a Program from an Internet Source Location ****
User Manipulation of Admin Image:
**
Problem: renamed a file. Solution: put renamed file back
Note, the failure I received is due to the fact that I renamed Setup.exe and Setup.ini so I could have multiple Admin images in one folder. Renaming files is where you'll see this problem. I'm editing the tile to reflect this information.
The workaround is to NOT rename Setup.ini, but to make a copy and rename it - leaving the original. **
Problem: renamed a file and transformed wrong MSI. Solution: reverse wrong MSI change, manipulate correct MSI
The wrong setup.exe was renamed in the .msi, as the file attributes do not match the columns in the file table.
Production Issues
Poor admin image support for a MSP
:
This problem occurs because the Data2.msp update file was not specifically designed to update administrative installations. Consequently, the Data2.msp update file is unable to update the Microsoft Internet Explorer and Windows Installer files on your administrative installation for CD2.
Poor admin image support for a MSI
This problem occurs because the Wsrm.msi package contains references to the Msvcp60d.dll file and the Msvcrtd.dll file. These files are not included in the retail version of WSRM. Therefore, when you try to perform an administrative installation of WSRM, you receive the error message that is described in the "Symptoms" section.
Poor media labeling:
This problem occurs when Setup has completed installing the source files that are located on the installation CD-ROM that is in your shared CD-ROM drive. Setup cannot locate the next source file that is required because the file is not located on the CD-ROM that is currently in the CD-ROM drive. This file is located on the next installation CD-ROM.
Poor use of self-extractor
This problem may occur because of an interaction between the IExpress Deployment Kit (IDK) and the Office XP Web Components Setup program.
Poor localization of authoring
This problem may occur if there is an incorrect entry in the Data1std.msi file.
Component Rules Violation and FASTOEM
:
Installing <Product> with the following configuration will fail with a 1308 internal Installer error:
- Using the FASTOEM property (requires at least Installer 1.11)
- Specifying the Feature_Global and Feature_ENG features to be installed locallyThis configuration fails because both of the above features install the same file: foo.txt. This causes a problem with FASTOEM because instead of copying the source files during the install, it moves the files. So, when the first component (the Component_Global component, which belongs to the Feature_Global feature) installs the foo.txt file, it moves it from the source to the destination. Then, when the second component (the Component_ENG component, which belongs to the Feature_ENG feature) attempts to install the foo.txt file, it is no longer available/present at the source.
OS or Chip Dependent Source Path referenced on Unsupported OS
There’s one bug that goes something like this: Say you parameterize x86 in your source path and set the parameter using an OS call. Now imagine a new chip comes along, ia64 for instance, and the setup program didn’t block attempts to install on unknown chips unknown at release time. I see there are reports on the web of the same problem in reverse for OSes where someone attempted to install a W2k or greater product on a Win9x box and the parameterized path failed.
Engine Domain Issues
bad local MSI file or configuration
: I’m not entirely certain this is the correct diagnosis but I presume the fix works anyways
There is this report of a Picture It!: You receive an "Internal error" error message when you run the Setup program
This issue may occur if there are mismatched Installer files and (or) registry keys for the program that is being installed.
Other instances
Bug: MSI 2.0 engine for HTTP
FIX: Error 1308 When You Install a Program from an Internet Source Location
This problem occurs because of a bug in the Windows Installer installation service. Installing from an Internet source location is supported and should work as expected, regardless of the files in the IsolatedComponents table of the Installation .msi file.
Constraint: Use of Multiple Media Readers (Jukebox) not supported
Share Media on Network Not Supported:
[Author: Robert Flaming]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.