SDI problem

  • Thread starter Thread starter DPM
  • Start date Start date
D

DPM

I'm trying to create a bootable recovery CD using the instructions in
http://msdn2.microsoft.com/en-us/library/aa460091.aspx. I'm able to build a
bootable CD, but when I try to execute the line "sdimgr.wsf recovery.sdi
/writedisk:0 /yes" my system declares that it cannot open "sdimgr.wsf", and
would I like to choose an application that will?

Now, I've successfully executed "regsvr32 sdiaut.dll"; what else is
required?

Thanks for your help.
 
Dean,

SDIMgr is a WHS script. Please first make sure the Windows Script Host engine components are included in your image. Second, please
make sure you've got association for the .WSH files to be launched with wscript or cscript.
Otherwise just launch the command you mentioned with the wscript.exe in front.
 
Explicitly adding CSCRIPT on the command line will invoke the script, but
then it aborts with a "Class not registered" error.

I got the sdimgr.wsf from "C:\Program Files\Windows Embedded\utilities"; is
there a better one somewhere else?

Thanks,
Dean
 
Dean,

First thing comes to my mind is the sdiaut.dll. But you said you already registered it, did you?
I don't recall any other "hard" dependency of the SDIMgr script. I could easy make sdiaut.dll working on various Minlogon images.
(some basic obvious stuff needs to be added such as COM/OLE, Win32 APIs, Shell APIs, Advanced and Setup API sets etc.)

Did you check if you got all the dependencies of the sdiaut.dll in the build?

The Windows Embedded\utilities is the only place you can find those tools under.
 
KM,

Just to clarify: I'm running the script under WinPE - I want to DEPLOY XPe.

Regards,
Dean
 
Dean,

Oh, I missed that. When somebody talks about a recovery solution on XPe my first through is a small XPe image (much more beneficial
over WinPE approach).
Anyway, you probably know about the know issue with SDI tools is that the sdiaut library function cannot be launched on a read-only
media. In other words, if you run SDIMgr, that calls into the sdiaut, on a bootable CD it will fail and will say something like
"Access denied" for not only writedisk command but for readdisk command as well.
More about this issue you can read here:
http://groups.google.com/group/micr...d/browse_thread/thread/98d5f893ff2e4884?hl=en


What's confusing is the error message you mentioned below. It does sound different from what I've seen so far with the SDIMgr (I've
gotten down to the Access Denied messages). Again, my first thought would be sdiaut.dll not registered. Did you check in registry if
the library got really registered?
If it did, you will probably have more luck firing that command with Regmon/Filemon/ProcessMonitor tools running in background to
see what's going on in the system.
 
KM,

I read the thread you provided - so the upshot is that WinPE cannot be used.

Someone needs to kick a chair at MS - that article should be taken down if
it's not workable. Did the author actually follow his own steps? How did
he get it to work?

Thanks,
Dean
 
KM,

You said below: "Did you check if you got all the dependencies of the
sdiaut.dll in the build?"

This implies to me that there is a component in the database that contains
sdiaut.dll, but if I search for it (visibility=100) I cannot find such a
component.

Did I misunderstand you?

Regards,
Dean
 
Dean,

Yeah, I am actually surprised the article didn't get fixed. It's been a while since the time we discovered the discrepancy.

Anyway, I still prefer XPe vs PE. In XPe I am in control of all the components I include in the build. For the sole purpose of
recovery my XPe images always much smaller than PE.
If went with PE, I'd only vote for PE 2.0 which is really nice product out there. But, I suppose, licensing would change.
 
Dean,

Well, I wasn't clear in my post. Sorry.
I didn't mean any component (there is certainly no components for SDI stuff in the XPe database). I just meant you to check the
binary dependency of the tool. You can use DependencyWalker to check the static dependencies (pretty much those I already mentioned)
+ the DependencyWalker profiling feature to see if anything missing on the dynamic side.
 
Back
Top