Major performance issue with Windows 7, Office 2007 and documents in the IFS
I'm stumped... Anybody else having (or had) major performance issues with Windows 7, Office 2007 and documents in the IFS of a System i? If you've been able to resolve the problem, please share with me. I do not have this problem with XP or Windows 2000 PCs. I even have an XP PC with Office 2007 that's working fine.
I've applied the IBM recommended changes to the Windows 7 PCs and have seen no difference. We have a 9406-520 at V6R1 with the next to the latest cume and all Netserver PTFs applied.
IBM ran a trace and here is the response
NetServer development has reviewed the trace and found that this is a case of the Windows client spending a lot of time trying to access /srvsvc.
Windows attempts to open a named pipe (srvsvc) that NetServer does not support. NetServer returns a normal OPERATION_NOT_SUPPORTED error, It appears that the Windows side is doing some sort of delayed retry of an operation after NetServer returns to error on the connection to srvsvc NetServer development has also tried doing some changes in their code so that they return an access denied or file not found error, hoping that Windows 7 would handle it differently, but results did not change.
Here's what I can find about srvsvc. This all came from a Google search and not from a Microsoft site, so it is word of mouth only. Srvsvc (C:WinNTsystem32srvsvc.dll) is part of SMB (Server Message Block) and CIFS(Common Internet File System) protocols used by windows. One online source says it is a 'file system driver' and that it supplies connections that are requested by redirectors on the client side and gives them access to the resources they request. It sounds like it passes both requests and data.
From several traces we've seen, it appears the XP client accepts the failure to connect to srvsvc and falls back to some classic LANMAN flows to get the information it wants, whereas the Windows 7 machine does not.
I would be happy to work with someone from Microsoft to try to gain insight into this problem
It is valid for a file server to reject the srvsvc call as is done by NetServer and ultimately Microsoft's code, which is issuing that call, needs to better handle the failure.
Software/Hardware used:
System i, V6R1, 9406-520, Windows 7, Office 2007
I've applied the IBM recommended changes to the Windows 7 PCs and have seen no difference. We have a 9406-520 at V6R1 with the next to the latest cume and all Netserver PTFs applied.
IBM ran a trace and here is the response
NetServer development has reviewed the trace and found that this is a case of the Windows client spending a lot of time trying to access /srvsvc.
Windows attempts to open a named pipe (srvsvc) that NetServer does not support. NetServer returns a normal OPERATION_NOT_SUPPORTED error, It appears that the Windows side is doing some sort of delayed retry of an operation after NetServer returns to error on the connection to srvsvc NetServer development has also tried doing some changes in their code so that they return an access denied or file not found error, hoping that Windows 7 would handle it differently, but results did not change.
Here's what I can find about srvsvc. This all came from a Google search and not from a Microsoft site, so it is word of mouth only. Srvsvc (C:WinNTsystem32srvsvc.dll) is part of SMB (Server Message Block) and CIFS(Common Internet File System) protocols used by windows. One online source says it is a 'file system driver' and that it supplies connections that are requested by redirectors on the client side and gives them access to the resources they request. It sounds like it passes both requests and data.
From several traces we've seen, it appears the XP client accepts the failure to connect to srvsvc and falls back to some classic LANMAN flows to get the information it wants, whereas the Windows 7 machine does not.
I would be happy to work with someone from Microsoft to try to gain insight into this problem
It is valid for a file server to reject the srvsvc call as is done by NetServer and ultimately Microsoft's code, which is issuing that call, needs to better handle the failure.
Software/Hardware used:
System i, V6R1, 9406-520, Windows 7, Office 2007
ASKED:
December 20, 2010 4:00 PM
UPDATED:
February 16, 2012 4:50 PM
Answer Wiki:
I found a few things to change in W7 that helped me.
1.
Hotfix
There is a hotfix at http://support.microsoft.com/kb/978869 that fixed my problem.
2.
1. Click on the Start button.
2. Type SECPOL.MSC in the search window.
3. Press Enter.
This will start the security policy editor in the Microsoft Management Console (MMC).
4. In the security policy editor, select Local Policies .
5. Select Security Options on the left side.
6. Scroll down to and double-click Network security: LAN Manager authentication level .
7. On the Local Security Setting tab, drop the list of options down and select Send LM & NTLM - use NTLMv2 session security if negotiated .
In addition, the SECPOL.MSC setting Network Security: Do not store LAN Manage hash value on next password change must be set to Disabled (meaning that the LANMAN should be stored when the password is changed).
A restart of the PC is required after making this security change, in order for the change to take effect.
3
Many Windows 7 users have seen performance issues when opening IFS documents on a NetServer network drive. To correct this problem, do the following from the Windows toolbar:
a. Click on Start.
b. Click on Run.
c. Type services.msc and click [ok].
d. From the list of Services listed, double click on Web Client , and change Start-up type from Manual to Automatic. This value defaulted to Automatic in Windows XP. The default was changed to Manual in Windows 7. Having this service automatically start up (and therefore always active) should improve performance significantly.
To see all answers submitted to the Answer Wiki: View Answer History.
Having the same issue with Windows 7 and Office 2010. Spoke to IBM today and they suggested a trace. Recently upgrade to V7R1, thinking this might help.
I have tried all of the above,and there is no improvement. Did a trace and this is what I got from IBM.
In the trace we see Windows sending a request to the iSeries for srvsvc. The iSeries responds with Function not supported.
Windows keeps sending the srvsvc request to the iSeries. We are not sure if it is expecting to get a different response from the iSeries, or what.
Then Windows decides to go out to http port 80 and see if something on port 80 will respond, which it does not because NetServer does not use this port.
Windows makes a bunch of requests trying to contact port 80, which is all eating up time and delaying what you are trying to do.
In the past when we have seen Windows try to access port 80, it has been when the Web Client service was running. If it was not running on the PC you traced, we have no way of telling why Windows was trying to access port 80. This would be a question for Windows Support.
Work around is to save the file to the pc and then copy to ifs folder.
This has a lot to do with familiarity with Windows 7.
Based on my last project, which expand to using Windows 7 and Windows XP, I would convert the programs to run compatibility with winXP sp3 in the windows 7 and turn off UAC. I hope this help.
:/
Are you saying install windows xp mode?
Not sure how to do this, convert the programs to run compatibility with winXP sp3 in the windows 7 and turn off UAC, can you explain in more detail
try disabling the the web client
Two parts.
Permission and compatibility.
You can right click on the program, and select properties, then select Compatibility, select Change settings for all users. This way, you are setting it for all users. Set the XP SP3 if that’s what works on your PC XP with Office 2007. And checked, run as administrator only if necessary.
Next part is Windows 7 have a great revamp on firewall. There are two parts to it. First part is internal firewall called work firewall, and another call Public firewall. You just need to tinker the work firewall. Go to Windows(Start), at search type Firewall, select result to run Firewall, go to Properties, and you will see Domain, Private, Public, I would try to turn them all off momentarily, to test out the software issue you are dealing with. Once proven, then you know your buddy-firewall has been the culprit
Sorry for the late post, my real IT job is quite demanding at times.