SC Pro 3.5 on W2K

[Ruford]

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[loren_d_c]

It sounds like the 'upgrade' to the new OS and new IIS caused a change
in the authentication you had set for the bo directory or changed the
login for the system user to login to the domain. Try re-visiting these
settings and see if there is a way to turn off the DOMAIN login for the
user or directory.

-Loren

Ruford wrote:

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[Ruford]

Well, once again Loren -- I have to thank you for being able to point
me toward the obvious. Any ideas what's happening when the
sb reports an error trying to run wsendmail?

"Loren" <loren_d_c@yahoo.com> wrote in message
news:3B5C9F33.97D7D7AB@yahoo.com...

It sounds like the 'upgrade' to the new OS and new IIS caused a change
in the authentication you had set for the bo directory or changed the
login for the system user to login to the domain. Try re-visiting these
settings and see if there is a way to turn off the DOMAIN login for the
user or directory.

-Loren

Ruford wrote:

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[loren_d_c]

Not sure, but I would try using the latest diagnose.exe from the shopsite.com
anonymous ftp site rather than nt_test.exe, even though it is for a newer
version of ShopSite. You may get errors when it is checking files and
settings because some files and directories that it is checking don't exist
in ShopSite 3.5, but the mail tests should work just fine.

You could also try executing wsendmail from the commandline and see what
happens. Maybe also check permissions on the exe and the ini file. Perhaps
the IIS user doesn't have permission to execute it, but the user that is
logged in through the back office is. That might explain why the cart doesn't
work but nt_test.exe through the backoffice does.

-Loren



Ruford wrote:

Well, once again Loren -- I have to thank you for being able to point
me toward the obvious. Any ideas what's happening when the
sb reports an error trying to run wsendmail?

"Loren" <loren_d_c@yahoo.com> wrote in message
news:3B5C9F33.97D7D7AB@yahoo.com...
It sounds like the 'upgrade' to the new OS and new IIS caused a change
in the authentication you had set for the bo directory or changed the
login for the system user to login to the domain. Try re-visiting these
settings and see if there is a way to turn off the DOMAIN login for the
user or directory.

-Loren

Ruford wrote:

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[Ruford]

Hmm, I don't know -- the only thing I could see is that I did not
have write or change access on the sb and bo directory trees
from nt_test.exe and diagnose.exe -- however, setting these
did not work.

I also tried changing my bo mapping to let me come in via
anonymous access so that it would run as the same web user
as a customer, and did the wSendmail test which worked fine
which would rule out the question of user rights to at least run
the program...

I also see the files created just fine in the sb/ssm_tmp directory.

I'd appreciate any ideas at this point, since it's not giving me
a terrible amount of information such as say the string it's
using to execute the wsendmail invocation or what the return
codes were.

"Loren" <loren_d_c@yahoo.com> wrote in message
news:3B5CAE53.49267CE3@yahoo.com...

Not sure, but I would try using the latest diagnose.exe from the
shopsite.com
anonymous ftp site rather than nt_test.exe, even though it is for a newer
version of ShopSite. You may get errors when it is checking files and
settings because some files and directories that it is checking don't
exist
in ShopSite 3.5, but the mail tests should work just fine.

You could also try executing wsendmail from the commandline and see what
happens. Maybe also check permissions on the exe and the ini file. Perhaps
the IIS user doesn't have permission to execute it, but the user that is
logged in through the back office is. That might explain why the cart
doesn't
work but nt_test.exe through the backoffice does.

-Loren



Ruford wrote:

Well, once again Loren -- I have to thank you for being able to point
me toward the obvious. Any ideas what's happening when the
sb reports an error trying to run wsendmail?

"Loren" <loren_d_c@yahoo.com> wrote in message
news:3B5C9F33.97D7D7AB@yahoo.com...
It sounds like the 'upgrade' to the new OS and new IIS caused a change
in the authentication you had set for the bo directory or changed the
login for the system user to login to the domain. Try re-visiting
these
settings and see if there is a way to turn off the DOMAIN login for
the
user or directory.

-Loren

Ruford wrote:

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[tom]

I just encountered a similar problem. I run Shopsite 4.3 on NT 4.0.
Yesterday, after I downloaded the latest Microsoft Windows update, my server
could not be booted up again! NT Repair did not work. Reloading NT also
failed. So I had to load W2K.

I cannot get Shopsite to run since then. All the static pages are
accessible. However, whenever I go to the shopping cart or try to go to the
admin section of Shopsite, this is what shows up:
.........
CGI Error
The specified CGI application misbehaved by not returning a complete set of
HTTP headers. The headers it did return are:

..............
If anyone has any suggestion so I don't have to reload Shopsite, I would
greatly appreciate it.

"Ruford" <rfisher@neocom.net> wrote in message
news:9ji6j3$o80$1@support.shopsite.com...

I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert

[loren_d_c]

Robert's problem with DOMAIN being appended before the login name can be
solved by going into the IIS management console, choosing the bo
directory or virtual directory, right click, go to Properties, go to
Authentication (I think, I am not in front of a windows machine right
now) and turn off the option to require a domain for login. Those may
not be the exact steps, especially since I am more familiar with the IIS
console on NT, but it should give you something to go on.

Tom, your problem may have to do with the registry being overwritten.
ShopSite makes sure that .cgi extensions are mapped to executables, and
I believe the cygwin1.dll file may also get registered somewhere. You
may be able to fix this by re-installing ShopSite, but rather than
installing it in the same directories as it is currently in, install it
in a bogus or temp directory. This way you can get the registry entries
back in, and then just delete your new ShopSite install.

Hopefully that helps. I am pretty sure it can't hurt.

-Loren



tom wrote:

I just encountered a similar problem. I run Shopsite 4.3 on NT 4.0.
Yesterday, after I downloaded the latest Microsoft Windows update, my server
could not be booted up again! NT Repair did not work. Reloading NT also
failed. So I had to load W2K.

I cannot get Shopsite to run since then. All the static pages are
accessible. However, whenever I go to the shopping cart or try to go to the
admin section of Shopsite, this is what shows up:
........
CGI Error
The specified CGI application misbehaved by not returning a complete set of
HTTP headers. The headers it did return are:

.............
If anyone has any suggestion so I don't have to reload Shopsite, I would
greatly appreciate it.

"Ruford" <rfisher@neocom.net> wrote in message
news:9ji6j3$o80$1@support.shopsite.com...
I was running Shopsite Pro 3.5 on a NT4 machine with
IIS 4 when a hardware failure caused a problem with
a SP upgrade, and so the decision was made to replace
the bad piece and upgrade to W2K.

My problem however, is that now the old shopsite will
not work -- for the shopping basket, the only problem I
encounter is that it claims it can't send e-mail via the
wSendmail program, but if I try it from the bo/nt_test.exe
it will send e-mail so...*shrug*

My bigger problem, is getting to the data for the orders,
products. When I try to enter via the /bo/ directory on W2K
with IIS5, it thinks the username is DOMAIN/user so when
the programs such as start.cgi or dbextract.cgi are used, they
are looking for a file called DOMAIN\user.auth rather than
user.auth -- I tried making a directory called DOMAIN, but
then I just run into auth file problems.

Does anyone have any ideas? I'm open to upgrades, but I
need to maintain the data that was there before the crash and
my backup tapes only have the *.db files, not a flat file dump.

Thanks,
Robert