Ghost Solution Suite

Can one of the developers or the experienced guys give me examples of what might cause the following error when deploying an ai package.

"Install Engine: Error: Due to a network problem, the user hive cannot be loaded; all users' personal settings may lost."

There does not seem to be any network issue it seems to be AI package specific.
On occasion I've resolved the issue by editing the ai package and replcing the path for the All Users folder with the system variable $AllUsersDir$, but in my current case (SQL 2000 Client Tools package) it is not working.

I'd be interested to try and work out why this is happening as although it does not seem to stop the deployed package running, it appears to be preventing batch files and scripts running correctly.

Well from a bit of messing around it seems to be related to a problem in the os image itself.

Having tried the same ai package on the same machine but with a windows 2000 image loaded there was no error. So I thought I must have built the package on a 2000 box and I would need to do a package specific to 2003sp1 (although most packages I've built work on several operating systems).

I rebuilt the package on 2003sp1, reloaded the os image then the package and it still failed. I Tried the same package on a different model machine with it's own 2003sp1 image and it worked.

I tried it on the original machine with a 2003 no sp image and it worked. So I used the 2003 no sp image and applied sp1 and all the current hotfixes and updated my 2003sp1 image. The package now works with it. Not sure what sort of problem there must have been with my original 2003sp1 image as other packages deployed without error. But at least now I can deploy without problems again

Thanks for that explanation, Bryan. I don't know what that error means either, but perhaps with the lead you've given us we can try and recreate a similar situation here - one thing with some of these errors is that they indicate situations where the original developers were being (sensibly) cautious, but if they are happening in specific situations we can often work out a way of handling an error.

Handling errors you've never seen is tricky, but once we know the circumstances in which it can be provoked it's usually not too bad - especially if we can produce the problem on demand, because testing error-handling code is extremely difficult otherwise.

If you do have a package that shows a problem fairly consistently, if you've willing to make it available to us that might help.

Thanks for the reply Nigel. I've sent you an email about getting the package to you (why did I think of spy movies when I typed that :) )