RDeploy Problem: URGENT
We had a working imaging process on DS 6.8 for over 3 years.
As of earlier this week, we started receiving an error 41 when rdeploy is called.
Rdeploy opens successfully, has a mapped drive to the appropriate winxp.exe self extracting image, winxp.exe is present along with .002 files. Permissions have not been modified on the .\images share. Attributes for the files have been verified.
When I place a pause at the end of my script command, on the target system i receive the following message: the file could not be opened.
Bottom line, everything is in place the way it was when created in 2006.
The error 41 produces an rdlog file with the following information:
Error description:
The file could not be opened.
(Note: The file does not exist.)
(Filename: v:\winxp.exe)
Possible causes:
A file that was expected to exist does not exist.
You do not have permission for this operation on the file or directory.
Possible resolutions:
Make sure the file exists and is accessible.
If the missing file is part of this program, reinstall the program.
Fix the permissions on the file or directory.
==================== Technical details ====================
Logfile = created Thu Sep 17 11:11:53 2009
Build = rdeployt.exe 6.8 (8192)
Cmdline = u:\rdeploy\windows\rdeployt.exe -noprompt -md -Fv:\winxp.exe -nobw -nooem
Status = 41 (0x29)
Source file = imglib\fio\osfile.cpp
Line number = 287 (0x11f)
Stack trace = 0x44de20 0x44dbb8 0x44fd7d 0x4045ca 0x4040cf 0x402fd8 0x411354 0x401d8c 0x40d62d &Known=0x4bf800
File name = v:\winxp.exe
Note = The file does not exist.
Imaging library revision = 8192 (win32-x86-release build, Wed Sep 06 22:46:48 2006)
Anyone ever see this error message? Contacted Altiris, the engineer has never seen this problem.
A few things to try
Is this happening through PXE or through bootable CD/DVD? If PXE, what is your preboot OS (Dos, Linux, or Windows).
I'm not sure what your file path is, but if you browse to v:\ can you create a new .txt file in that directory?
Can you then boot to V:\ and confirm that you can both read and delete the .txt file you created?
From the DS server, Windows Control Panel > Altiris Deployment Server > Options > Drive Mappings - have you confirmed that the V:\ mapping is still listed and is correct?
Also - you haven't changed your NT Lanmanager authentication have you? This needs to be set to allow both NTLM and NTLM 2.
And finally, what is the size of your image files? If they are above 2GB in SIze and you are booting in DOS that could be part of the problem.
Vortex - happening via
Vortex - happening via PXE. Preboot is WINPE via bootworks.
Yes, can create new file in the path of v:\ and access test.txt booting to v:
The v:\ drive is being mapped via a VBS script which is called upon during the image process - this is not a mapped drive via Altiris DS Server Options
I don't know if there was a change made on NT LANManager - will check.
The image is 2.5GB - please note the baseline image was created in 2007 and has been functioning as of earlier this week.
Since my posting, I have tried imaging and it worked one but the other three times, it has failed again. Something is preventing rdeploy from accessing the image file.
Also noticed where if the switch port is hard set to auto, it works better but it is not a guaruntee...if the switch port I'm imaging through is set to 100 Full - will not image when it used to all along. This was also just discovered this morning.
Thought this was a silver bullet with something that might have changed at the switch level but I'm able to get it to work but not often.
This process was flawless and now it barely works, if at all. This is widespread across North America - not jsut my test connections.
Were the switches upgraded?
Were the switches upgraded? Maybe portfast isn't on. https://kb.altiris.com/article.asp?article=3096&p=1 It shouldn't even PXE boot if this was the case, but who knows.
No physical upgrades on
No physical upgrades on switches, no firmware upgrades. But we are in the process of setting up a sniff to see if that leads us anywhere.
Follow up: Determined that if
Follow up:
Determined that if the switch is set to a hard setting (100 Full), the rdeploy can not access the mapped drive. Verified from open command window during process, try to change drives from f:\ to v:\, cannot connect.
The sniff indicates the same, can't access the mapped v drive.
If we change the switch port to Auto, more often than not, the job works but sometimes it still bombs at this stage.
Keep in mind, this was a complete working process for 3 years and now there's confusion on connecting just to this one location while all throughout the process prior to rdeploy, it's mapping drives, copying winpe boot automation, passing log files, running .bat files...
Truly strange.
Would you like to reply?
Login or Register to post your comment.