The best practice for publishing an Internet facing SharePoint site is to use ISA as a reverse proxy solution to provide an additional layer of security between the SharePoint portal and the end user. This eliminates any traffic originating from the Internet from ever reaching the internal protected network. Instead the traffic terminates in the DMZ at the ISA server and it in turn performs Active Directory or Forms Based authentication through LDAP, LDAPS, or Radius. It then proxies the content from the internal network to the DMZ then to the end user.
One of the “gotchas” for publishing SharePoint through ISA is the way ISA handles authentication and cookies. By default, ISA will not issue persistent cookies to the web browser. This requires your users to authenticate multiple time while navigating the portal between site collections or opening a document in a document library. This of course provides maximum security however its also a nuisance to most users.
This setting can be changed to allow persistent cookies which will then behave like Integrated Windows Authentication once the user has logged in the first time. The downside to this configuration is the user will remain logged in until they manually sign out even if the browser is closed or the computer restarted.
An acceptable compromise is to configure persistent cookies only for computers selected as Private Computers during the login process. This allows users to select how ISA should act depending on which computer they are accessing SharePoint from.
To set persistent cookies, go to the forms tab on the web listener for that ISA rule and click Advanced:
Now when the user selects Private Computer, ISA won’t keep asking for authentication:
Users should be educated on the consequences of this choice as to not compromise the portal by using this option on public Internet terminals or publicly accessible computers.
This week I had a customer who was experiencing service loss on one of the VMs in their 2008 R2 Hyper-V environments. We initially started looking at disk as the source of the issue since the customer was using a Fiber Channel SATA SAN. I moved the LUNS into their own raid groups to assure each had their own spindles. I also converted the data drives to fixed length VHD files attached to the synthetic SCSI controller.
While these changes did drastically increase performance, the server would still have periods where it would “pause” for a second or two under heavy duress. Finally an error popped in the event viewer that gave us a solid lead.
The browser service was unable to retrieve a list of servers from the browser master \\PDCEmulatorName on the network \Device\NetBT_Tcpip\{SID}
Browser master: \\PDCEmulatorName
Network: \Device\NetBT_Tcpip_{SID}
This event may be caused by a temporary loss of network connectivity. If this message appears again, verify that the server is still connected to the network. The return code is in the Data text box.
For more information, see Help and Support Center at
The VM itself is temporarily losing network connectivity which is causing “pauses” during file activity. Microsoft has released a hot fix to handle the above issue. The hot fix needs to be installed on the host computer with the Hyper-V role. In this case on both 2008 R2 Server Core that comprise the environment.
The hot fix can be located here:
http://support.microsoft.com/kb/974909