SuperOffice 7 Web and SO_ARC on different servers

I’m playing around with SuperOffice 7 web. I’ve managed to automate the process of creating separate websites per SuperOffice instance, but after the initial setup I started getting some weird errors.
I’m far from, done with all this, and I defiantly don’t know everything I need to know to make all this work, but I’m taking things as they come.

When downloading files, I would get errors like

My first though was I hadn't escaped the file path properly.
When setting up SuperOffice web I found that these 4 files needs to be updated
~\bin\Reporter\SoReporter.Executer.exe.config
~\bin\BatchService\SoBatchService.exe.config
~\bin\Reporter\SuperOffice.CONFIG
~\Web.config
I modified my SuperOffice PowerShell snap in to support loading all files and changing the content, to make it easier for me while automating the process.

In the above error the SO_ARC is places on \\fs01\Customers\SOTEST2\APPS\SO7\SO_ARC so that’s what I had in SoBatchService.exe.config, SuperOffice.CONFIG and Web.config. … I escaped the string with $SO_ARC = $SO_ARC.Replace("\", "\\") … Provisioned the website and tried again.

Still now luck, so open Process Monitor and look what's going on …. AAHHH!

That’s weird, I specifically set the credentials I want it so connect as and yet its accessing the files as IUSR …

    <Documents>
      <!-- Location of SO_ARC -->
      <add key="ArchivePath" value="\\\\fs01\\customers\\SOTEST2\\APPS\\SO7\\SO_ARC" />
      <!-- Location of template folder.
                    This folder only needs to be specified when it is other than default. -->
      <!--<add key="TemplatePath" value="\\\\qa-build\\StateZeroSoArc\\Template" />-->
      <!-- Location of temporary folder for streaming files.  
                    This path must resolve to the same location for farms/culsters. -->
      <add key="TemporaryPath" value="c:\\temp" />
      <!-- Impersonate user when accessing the document archive or the temporary folder  -->
      <add key="ImpersonateUser" value="False" />
      <!-- Name of the user to impersonate with -->
      <add key="ArchiveUser" value="soadmin_SOTEST2" />
      <!-- Password of the user to impersonate with -->
      <add key="ArchivePassword" value="SuperSecret" />
      <!-- Domain of the user to impersonate with -->
      <add key="ArchiveDomain" value="INT" />
      <!-- Size of internal buffer in KB -->
      <add key="BufferSize" value="32" />
    </Documents>

Ah well, no worry, I modified my script to create an application pool with a domain account and set the websites anonymous account to run as the application pool.

# Set application Pool identity
Set-ItemProperty ('IIS:\AppPools\' + $InstanceName) -name processModel -value @{userName=($ADDomainName + '\' + $SOAdminUser);password=$SOAdminPassword;identitytype=3}
# Set Application Pool Identity as Anonymous User 
Set-WebConfigurationProperty -filter /system.webServer/security/authentication/anonymousAuthentication -name userName -value "" -PSPath IIS:\ -location ('IIS:\Sites\' + $InstanceName)

And now it works… Guess that is a bug, or I don’t understand the parameters well enough.

And tonight I’m going to throw some love at reporting … Every time I try and generate a report I get this error in the browser after a minute’s time.

Updated 27-09-2011: Problem solved. First of all, I had forgotten to create the DSN link. But it still failed.
There was no error messages being generated anywhere, so I fired up process monitor and had a look. And sure enough, SoReporter.Executer.exe was getting access denied creating so_log.txt, so I gave the application poll write permissions in the /bin and had a look. After doing that, every time I tried generating a report, instead of getting the above error I would know be logged out of the website. hmmm, strange …

After looking at some of the warnings in the normal log files I started to wonder if “Failed to parse Assembly 'Edanmo.OleStorage, Version=1.0.847.22469,Culture=neutral,PublicKeyToken=8840063030bd4bce'.” had something to do with this so began looking more into errors after finding DLL files. Edanmo.OleStorage quickly lead me to MsgReader – DLL . I bet they chanced something in the code and was not in the mode for reflector, but since I know now I had something to do with mail I remembered seeing something in the above config files

    <Factory>
      <DynamicLoad>
        <add key="DefaultSoMail" value="C:\Program Files\SuperOffice\SuperOffice 7 Web\SuperOffice\bin\SoMail.dll" />
        <add key="SaleImpl" value="SuperOffice.Sale.Services.Implementation.dll" />
        <add key="ProjectImpl" value="SuperOffice.Project.Services.Implementation.dll" />

Now, I know that is not right. I remember thinking the first time I saw it, that I couldn’t harm pointing at the “wrong” directory. the DLL was there too … but I know better than that. so just for fun I went though all the config files mentioned above and removed the path

        <add key="DefaultSoMail" value="SoMail.dll" />

Love and be hold. We have a winner …. Now I can generate reports.
I modified my provisioning scripts, deleted everything and created all from scratch ( to fix permissions, things I had chanced in config files etc. ) and re-tested and it still works .. so that is the fix …