Hello Everyone, We have MOSS 2007 setup in a small 2 server farm, 1 SharePoint 2007 server (X64) and a database server. We have setup an intranet site for all the employees to access and it is working well and running smoothly. The issue we are having is that when a client initially accesses the Intranet site the initial load times is quite long,upwards of30+ seconds. It will display some of the site but it looks very bare, in the status I can see it says (18 items to load) which slowly counts down then the page shows up. Once the page is loaded accessing any part of the site is very quick, but if you press F5 to refresh the browser screen for any reason it does it again. So basically, as long as you don't refresh the screen the site will run very quick even if you close your browser and start a new session. I understand there are warm up scripts that you can put on the server to help speed things up after an IIS reset or reboot of the server, but this doesn't seem to be the same issue. If I log onto the server directly and load up the intranet site up locally it is always quick regardless of what user I log in with. Any thoughts would be appreciated. Thanks! Rob.

I reinstalled my pre-production machine. This time I used a fqdn for the database server e.g. dataserver.example.local instead of dataserver. Now it is a lot faster. I don't know if the network people at my site changed anything; it's a big place. Regards, Marcel

marnar, If I remember correctly, DNS queries are resolved before NETBIOS queries, so it is quite possible that would speed you up. Rob, Is there another computer /server that is residing on the same switch? You can view the website from that same server, and see if you are still having the problem or not, and then slowly work your way through your network topology to see where the bottleneck is. That may be a good way to convince your network guys of the problem at hand, if indeed the switch is the problem.

Rob, what is your Platform? What kind of servers are you using? OS? Enterprise edition? We are on HP BL25p G2 running Windows 2003 R2 STD for MOSS with MOSS Enterprise Edition.

I turned off Enable HTTP Keep Alives in IIS on the Sharepoint website and the stall problem disappeared Can someone verify this ?

marmar, Where did you disable the keep alives? Are you using any load balacing? We are using CSS for load balancing. I disabled HTTP Keep alives on my environment and can not access any of the moss sites. I believe our CSS also has keep alives enabled. I wonder if this would make a difference?

Can you give me more detail on the Server? We are wondering if is hardware related or not. That's interesting about the anonymous access and the SSL access working but not the intergrated access. You want to set up a chat on MSN MSGer? Maybe we can bounce ideas back and fourth?

feel free to add me to your contacts .. email is in my profile

Allthough Bardapony's solution seems to work I did some more investigation: - we are all running HP systems - if you setup SSL you will have noticed that the SSL version did not stall As I suspected the NIC driver I disabled TCP offloading and now it flies .. Procedure (might be slightly different if you don't have a NIC team setup): - Double click on the green HP icon in your systray - Select you network team and click properties - go to settings tab - In advanced listbox select TCP Offload Engine - remove the Enable check - Report to HP (or Microsoft ?)

We're having this problem as well, although it's not an HP system. I think it's intrinsic to SharePoint - I'm noticing a lot of other people having problems with the initial spin-up. I'll post if I figure out the solution to our specific problem.

The first time anybody visits the SharePoint site, it will take a while for it to load. This is the nature of .NET-based web applications. They have to cache DLLs locally, and so forth after an application pool reset. By default, the standard Application Pool configuration recycles the application pool every night. Verify that isn't your problem.

First, before I post any details, I'll note that disabling HTTP compression fixed the problem for us (we tried disabling TCP offloading first, so it may be a combination of both steps). I have a suspicion that this problem is caused by a proxy server, but I haven't confirmed whether or not our connections are running through a proxy, so I'll leave that as suspicion for now. First, I'll point to a KB article about the TCP offloading issue, in case you want to look into this further: http://support.microsoft.com/kb/936594 Second, I'll note that you can quickly disable HTTP compression on the client side, before attempting to do so on the server side. The steps are: 1. Open IE, go to Tools->Internet Options->Advanced->HTTP 1.1 settings 2.uncheck both HTTP 1.1 checkboxes (e.g. uncheck "Use HTTP 1.1") 3. CLOSE ALL IE WINDOWS.ALL of them. 4. Re-open IE. 5. Test. Third, I'll clarify the earlier post about how to disable HTTP compression on the SharePoint farm. I created a batch file that looks like: -- c:cd \inetpub\adminscripts cscript adsutil.vbs set w3svc/1111111111/Root/DoDynamicCompression falsecscript adsutil.vbs set w3svc/1111111111/Root/DoStaticCompression false cscript adsutil.vbs set w3svc/222222222/Root/DoDynamicCompression falsecscript adsutil.vbs set w3svc/222222222/Root/DoStaticCompression false cscript adsutil.vbs set w3svc/3333333333/Root/DoDynamicCompression falsecscript adsutil.vbs set w3svc/3333333333/Root/DoStaticCompression false cscript adsutil.vbs set w3svc/444444444/Root/DoDynamicCompression falsecscript adsutil.vbs set w3svc/444444444/Root/DoStaticCompression false cscript adsutil.vbs set w3svc/555555555/Root/DoDynamicCompression falsecscript adsutil.vbs set w3svc/555555555/Root/DoStaticCompression false -- Let me briefly explain how you need to customize this batch file: 1. Open up IIS. Expand so you see the "Web Sites" folder. 2. Click on the Web Sites folder itself. This will display a "details view" of all your IIS sites. 3. Write down the "Identifier" column for each of your SharePoint sites (I had 4). 4. Repeat steps #1-3 for all ofthe servers in your SharePoint farm. 5. Customize the script above, replacing "1111111111" with your first web site identifier, "22222222" with your second identifier, and so on. Note that your servers may not have identical setups, so check every server. 6. Back up the IIS metabase. 7. Run thisbatch file (I pasted directly into the command prompt)on each server in your farm. Run iisreset on each server afterwards. 8. Test.

We have a Staging server and a Production server with SharePoint 2007 installed. The slow initial load issue happens on the Production server, but not on the Staging server. As far as I can tell, the two servers are configured the same (both hardware and software). Disabling HTTP Compression fixed the issue on the production server. The Staging server has HTTP Compression enabled and works fine. Anyone could help explain this? And why "Disabling HTTP Compression" fixed the issue? We do not have proxy servers. Thanks!

My Sharepoint Project server 2007 site seems to run slow when a user first accesses it in the morning too. I had the same problem when it was installed on another server, but other custom web applications ran fine by responding quickly. I think Curtis Ruppe is correct in saying that the issue is caused by the need to cache DLL's after the application pool reset. I had a look at my site's application pool and there was a default setting which says "Recycle the worker processes at the following times" and "01:15" is set - this would seems to tie in with the fact that oursharepoint/Project WebAccesssite runs slow each morning on any initial access attempt. I ran a quick test and scheduled this to happen whilst I was accessing the site, as soon as the scheduled time came around, sure enough, the site had a slow response after the first access attempt on various pages. As a possilbe solution, perhaps the worker processes could be recycled less frequently to reduce the impact of this problem or perhaps a scheduled task could be created to automatically access the site on the server after the worker process has been recycled. Hope this helps others, -Si.

Please post the results you get from MS. I and I'm sure others, would be interested on the fix.

Hello.I have got the same problemand it seems not to be an intranet sharepoint sharing problem. I am using Moss over internet and some clients are complaining about this issue. In some computers the access to sharepoint takes over a minute to deploy the web page. Curious the login window opens immediatly, but the page takes to long to deploy.Trying, to solve this problem, to post solution.ps:Sharepoint 2007 w/ SP1

Allthough Bardapony's solution seems to work I did some more investigation: - we are all running HP systems - if you setup SSL you will have noticed that the SSL version did not stall As I suspected the NIC driver I disabled TCP offloading and now it flies .. Procedure (might be slightly different if you don't have a NIC team setup): - Double click on the green HP icon in your systray - Select you network team and click properties - go to settings tab - In advanced listbox select TCP Offload Engine - remove the Enable check - Report to HP (or Microsoft ?) I signed up just to say this solved our problem. Thanks for the help!

I checked your post. It was a network issue. I did not have to change any network settings or run any scripts. I have two nework cards. I had one of my network cards unplugged. DNS had a host mapping for the unplugged network card IP address. Once it saw that the site was not on that IP it looked otherwise to find the next mapping and found the site. This was what was slowing my site down. Under the SharePoint Web Sites properties I had the IP address unassigned. :p Plugged in the network card. Boom ... done !! Issues resolved.

This solution worked for me on a SharePoint Foundation 2010 install on SBS 2011. Disabling TCP offloading in the NICs did the trick! Thanks marnar!