Situation:

The following strange problem has occurred on a single file server running OmniOS r151018 (95eaa7e) serving files over SMB to Windows and OS X guests.

Saving certain files (.docx, .xlsx, some images) through the "Save as..." dialog window on a SMB share results in a lag of about 3 to 5 seconds, where the application does not respond at all, afterwards the file is saved normally.

The problem did occur "over night", without doing anything to the server, but it is difficult to pinpoint the exact date, as user complaints only came in some time after the first occurrence. After a reboot of the server, one vdev of the mirrored root pool was unavailable, but closer inspection did not find any faults on the device and it was reattached to the pool. The problem still persists.

Some observations:

• It happens on all Windows 7 clients
• It happens for all file sizes
• It happens on all shares of this machine, regardless of permissions
• It happens for faster storage imported on the host over iSCSI from another server
• Normal copy speed is 110 MB/sec over GBit Ethernet
• Data and root pool seem to be fine
• It does not happen on other file servers
• It does not happen when the file is saved locally, then copied over through explorer
• It does not happen on OS X (could only test it with OpenOffice)
• dmesg shows several counts of NOTICE: bge0: interrupt: flags 0x0 - not updated? with various values, but this was also the case before and did no harm

Further ideads/plans:

As there is no clear error message to be found, I might need to do some trial and error searching for the cause. Some things I will consider (results are in italics):

• Replace the Broadcom network card with an Intel card => did not make a difference
• Replace the root pool with SATA SSDs (currently SLC memory USB sticks which worked fine for over 3 years) => did not make a difference
• Check the network in between (hardware, by connection directly to the server)
• Traffic capture with WireShark: difficult if you don't know what you are looking for exactly
• Revert to a previous OmniOS boot environment/version to rule out software conflicts => did not make a difference
• Roll back Windows/Office updates to rule out bugs

• Remove files with : (colon) in filenames from snapshots, suggestion by txgsync on the reddit thread created by ewwhite => did not make a difference

  I've seen something similar to this when the Windows "previous versions" feature is enabled with automatic snapshots that include a ":" character. Just shooting at the wind with this, but may be worth a look as the ":" character is not allowed in Windows file names.

• Monitoring of file access: as suggested by shodanshok, I used DTrace and this script to monitor file access. I used it while saving the alread open file, removed unrelated output and personal information, and the result centers around three files:

  CPU ID       FUNCTION:NAME
  1   18753    fop_open:entry Open: Workbook
  0   18181 fop_create:return Create: temp_1
  0   18753    fop_open:entry Open: temp_1
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_1
  0   18888  fop_rename:entry Rename: Workbook -> temp_2
  0   18888  fop_rename:entry Rename: temp_1 -> Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_2
  0   18892  fop_remove:entry Remove: temp_2
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  

  The same procedure on another server where the problem does not occur yields a similar result:

  CPU ID       FUNCTION:NAME
  1   25182 fop_create:return Create: temp_1
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25889  fop_rename:entry Rename: Workbook -> temp_2
  1   25889  fop_rename:entry Rename: temp_1 -> Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_2
  1   25893  fop_remove:entry Remove: temp_2
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  

  I also added timestamps (walltimestamp) to the script, but in both cases all file operations take place at the same second. => did not make a difference

• Import disks on another host to check if pool fragmentation or disks are faulty => did not make a difference
• Move data and root pool over to identical machine to rule out cabling, mainboard etc. => problem does persist, so must be either the root pool (software) or a specific hardware that is incompatible with the software (or did suddenly become incompatible...)

Could you suggest anything else that be be the cause of this behavior? Or did you experience something similar? because I could not find anything helpful online, I suspect it is either a strange hardware problem (because it is limited to one machine) or a problem with Windows/Office.

Simple answer I am sure...I an trying to deploy Office 2010 to clients via the GPO startup script but am having issues. Soon as the computer starts, it prepares network connections then goes on to running startup scripts. Soon as my startup script runs to deploy offices, i get asked for a username and password to connect to the share...i have all permissions set for authenticated users can read and execute, and for testing purposes i put domain computers can do the same as authenticated users.

If anyone has any thoughts, that would be great.

We have an Apache Subversion server that we store (amongst other things) all of our documentation on. We have a lot of Word, Excel, PDF etc. documents in svn, and all of our users use TortoiseSVN as their client interface. A lot of those users will also browse the repo through a web browser, which (unfortunately) is often Internet Explorer.

Recently we started trialling Office 2010 (coming from 2003) and found that documents from the repo are opened differently when browsing with IE. Rather than IE downloading the file and then sending it to the appropriate app (after which it should just be a temporary copy stored locally), it sends the URL for the document to the app. The doc is downloaded by the app and then treated it as if it came from a Sharepoint server, i.e. the app tries to lock it and then upload any saved changes back to the server automatically.

From Googling, it appears that many people want this behaviour. However, we want to disable it - it doesn't fit with our existing processes. How can I go about doing this?

I don't have a lot of control over client machines, so solutions that involve disabling all Office document collaboration features like this for each client are not what I'm looking for. Besides, I couldn't find much that I could do other than disable the Office Document Cache Handler add-on in IE. The only client-side options that may be feasible are those that specifically disable this feature for our named server but leave it on for others.

So that leaves server-side solutions. I'm guessing that Office sees that the svn server has WebDAV support and therefore moves into a Sharepoint-like document management workflow. Is there any way to stop this kind of integration without disabling all WebDAV support on the server (assuming we could even do that)? We actually use svn's autoversioning a bit for other purposes so it's a required feature. I've found discussion of disabling the feature if it's actually a Sharepoint server, but it's not! My understanding of how this kind of thing works (i.e. Office client identifying WebDAV support on the server) is pretty limited, so please explain further if you can.

In case it matters, the server setup is:

Apache v2.2.8 and Subversion v1.4.6 on Ubuntu Hardy 8.04.

We are looking into various Office 2010 deployment methods currently.

I was wondering what people suggest?

Currently I am doing it via start up script (ugh) as MS doesn't allow it to install via MSI and GPO.

SCCM is an option, but should I be looking into using App-V instead of SCCM ?

I've created an unattended install of Office 2010 using the OCT. We are using a MAK rather than KMS (not my decision). Is there a way to activate Office 2010 after the install? Even though the key is set during the install, it does not activate.

I don't want the users to be prompted to activate since this is going to be in a lab environment.