WSSetup install on Windows 7 x64 causes autochk.exe to fail to run 1

[ramam1]

Here's a problem we just started seeing... anyone?


Product:
Sage 300 ERP 2012 RTM

Error Description:
Performing a WSSetup install on Windows 7 x64 causes autochk.exe
to fail to run when a filesystem check is scheduled.

How Reproducible:
100%

Environment:
Sambabox server, Samba 3.6 Domain providing logins, DNS, and WINS,
exporting \\Sambabox\accpac and \\Sambabox\accpacdata.
Permissions: Domain\Administrator: owner, full control;
Domain\SageUsers: r/o for program share, r/w for shared data;
Everyone: none.
Windows 7 x64 client workstations on both Dell Optiplex 990 and
a CentOS 6 KVM vm.

Steps to Reproduce:
1 Master (full) install of Sage 300 ERP on Windows 2008 Enterprise x64,
using the samba exports for program files and shared data.
2 Install Windows 7 x64.
3 Login to the workstation as the local Administrator. Open the
accpac shares as Domain\Administrator.
3 Run \\Sambabox\accpac\WSSetup\setup.exe on the Windows 7 workstation.
4 From C:\ -> Properties -> Tools -> Error Checking, select
"automatically fix file system errors". Select "Yes" to schedule the
check for the next reboot.
5 Reboot the workstation.
6 Observe the error message given below.

Expected Results:
Upon reboot, when a filesystem check is scheduled, it runs
successfully.

Actual Results:
Upon reboot, with a filesystem check scheduled, autochk.exe attempts
to run, but stops with the following error message:
"""
Checking file system on C:
The type of the file system is NTFS.

A disk check has been scheduled.
Windows will now check the disk.
Cannot open volume for direct access.
Autochk cannot run due to an error caused by a recently installed software
package.
Use the system restore feature from the control panel to restore the system
to a point prior to the
recent software package installation.
An unspecified error occurred (766f6c756d652e63 3f1).
"""

Additional Information:
Performing a rollback to a point in time prior to the installation
of Sage 300 ERP allows the filesystem check to proceed.

The error is not observed when the full install is done, only with
the workstation install.

UNC paths are used, not mapped drives.

This error does not occur with Windows XP x86_32 workstations.

Turning any of the following on or off does not help: UAC, Windows
Defender, "Prohibit User Installs" policy.

The error occurs without regard to either the update status of the
workstation or to whether any additional software, including Office,
is installed before Sage 300 ERP.

The error occurs whether the program and data folders are shared from
the samba server or from the Windows 2008 Enterprise server.

Neither Startup Repair nor manually running chkdsk.exe from the
Windows recovery environment solve this problem.

 

[Jay Converse]

If you're using autochk for any reason, you have a corrupt system to begin with. Start with a clean OS.

 

[ramam1]

Tuba, I'm not sure what you're getting at - perhaps I'm being dense.

Per the steps for reproduction the bug is reproducible by starting with a clean win7 install followed by accpac WS setup. Once WS Setup completes we reboot the win7 WS and the WS reports file system as corrupted. A fs check *before* WS Setup is run shows a clean file system but the fs check *after* WS setup reports a corrupted one.

 

[Jay Converse]

Contact Sage.

 

[ramam1]

After finding this issue we contacted Sage. They had no interest in figuring it out once they offered a work around they liked. Here is what they suggested.

use the full install on the workstation, putting the program files in c:\Accpac and the data files in c:\Data; you then edit the registry in order to change where accpac thinks that the data are: HKLM\Software\WOW6432Node\ACCPAC [->] International, Inc.\ACCPAC\Configuration\[->] SharedData;
​

That is they want us to have every workstation use it's own installation and then tweak the registry so that they do share a data share. That is not my favorite answer out of them. I'm hoping to do better here or failing that on the IT Toolbox reflector. We've also filed this bug report with Sage so they are at least aware of it.

 

[Jay Converse]

Aha. The problem is Samba. Install from a Windows server.

 

[ramam1]

The error occurs whether the program and data folders are shared from
the samba server or from the Windows 2008 Enterprise server.

 

[ramam1]

BTW Happens on Win7 32 bit as well as Win7 64 bit. Does not affect WinXP regardless of the version.

 

[DjangMan]

I did a quick Google and found that someone with the same sort of issue did the following:

I had exactly the same problem. This worked for me:
1. Uninstall antivirus (mine was AVG free v9)
2. Schedule chkdsk on restart
3. Restart
4. Now CHKDSK runs and fixes up he disk problems
5. Re-install AVG

I know that you don't have disk problems but I wonder if anti-virus software is playing a role?

 

[ramam1]

Thanks DjangMan. In our test environment we are running with no AV installed other than WindowsDefender which is disabled (normally we of course do have AV on our workstations).

 

[ramam1]

Update. It seems that when we run WS Setup the MSI for Sage Update Advisor fails to install - this is possibly the reason why there is a stale lock preventing from disk check from running. As we use a shared server install (and our users don't have admin privileges anyway) there is no value in installing the advisor. Anyone know how to prevent VS Setup from installing the update advisor?

 

[ettienne]

There is no way to not install Sage Advisor (grrrrrrrrrrrrrrrrrrrrrrrrrrr), but directly after running a workstation setup go uninstall Sage Advisor from Programs and Features. First stop the Sage Advisor service and exit it in the Windows Taskbar, otherwise you will have to reboot. FWIW I always uninstall Sage Advisor on the server and workstations, it's just another piece of useless bloatware Sage are releasing nowadays.

 

[ramam1]

Looks like someone at the office figured it out. WSSetup doesn't like UNC paths for the folders. Can anyone confirm (or deny!) that?
thanks much

 

[Jay Converse]

Denied, I use UNC all the time.

 

[ramam1]

I thought as much but we did a very specific A|B comparison. Must be something in our smb server setup then.
Thanks Tuba.