What kind of issues are you experiencing? If a NLB is in place, you can still hit an individual server and load the SP site bypassing the NLB (you'll need to make sure the site has alternate access mapping set for the server name).
But if you want to remove it, it should be straight forward, hop onto that box and uninstall SharePoint, it'll take it out of ...
I found interesting article about this issue here http://geekswithblogs.net/kjones/archive/2010/10/29/142510.aspx
Author created a small graphic files, copied them to C:\Program Files\Common Files\Microsoft Shared\web server extensions\1x\TEMPLATE\IMAGES and insert them to page footer. Because every WFE look to their own images directory, he can simply ...
I have found the best method of doing this is to modify your machine's HOSTS file for your load balanced URL to point to the specific WFE IP. This will direct all of your traffic to that one IP skipping the NLB.
HOSTS is located in c:\windows\system32\drivers\etc.
Add an entry like
Where 192.168.1.2 is one web front end ...
Yes, you need to ensure your published URLS for your farm are setup to use HTTP as the traffic from your Netscaler to the farm will be in HTTP.
This only matters for the published URLS as these are the URLS the Netscaler will use. Don't worry about the traffic between various servers in your farm as it doesn't make a difference from a SSL offload ...
You're mostly correct on both counts. You need a load balancing solution of some sort to distribute traffic between SharePoint web servers that are hosting content web applications accessed by end users. Windows Network Load Balancing (NLB) is one option you can use to provide that, but there are other options as well. NLB is a software-based load balancer, ...
Network Load Balancing is a type of clustering. It can be software or hardware based but if you are talking about SQL clustering which is used in SharePoint environment. Here's an example of how load balancing and SQL clustering works together,
"High Availablity" means both but "somehow" but depends on farm topology.
Check this MSDN article out for more ...
With SharePoint 2013 there is no need to configure sticky sessions (affinity) anymore, at least not for authentication. This is because login tokens are now cached in the new distributed cache service so every web server has them in memory:
However, it's probably not a bad idea to still use sticky ...
You should be able to see a ULS log entry on the WFE that is serving the request. It will only appear on one of the WFE's. It might also reveal other information about what's going on with the web part.
The defauly location of the ULS logs is here: C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\LOGS
Check out the ULS Log Viewer (...
Yes. You can use 2 WFEs without load balancing (via NLB or other hardware).
It won't automatically fail-over, but if one WFE has an issue, you can access your content via the other WFE.
If you are using a dns name (e.g, http://portal.company.com) instead of machine names you have two options:
1) enter both IPs for DNS entry which will provie "dumb" load-...
Add the following line to the hosts file ("C:\Windows\System32\drivers\etc\hosts") on all of your SharePoint Servers:
That'll make them always use themselves as the server when referring to SPLOAD instead of having to go through the load balancer and maybe start talking to one of the other servers
To answer the NLB question, the only NLB you need to handle is for web traffic to your Web Applications (potentially including Central Admin). Use an NLB hardware appliance or HA Proxy -- I would not recommend using Windows NLB. Services, such as Search, MMS, etc. are handled by SharePoint's internal load balancer.
I would strongly suggest running all of ...
It would help to know what load balancer you are using so I can help narrow the possible cause but the likely reason is detailed below.
If you are using a hardware based load balancer such as F5 LTM then it will load balance traffic across the two nodes on the ports you specify. You will need to setup monitors to probe the health of the nodes and based on ...
Fixed the issue by applying correct AAM settings. Here's how I did it.
Deleted "Custom" zone and only kept "Default" and "Internet" zones. In Internet zone I defined www.example.com as public URL. I then added following Internal URLs in "Internet" zone.
No need to change anything in IIS... just start the web application service on all WFEs and configure Alternate Access mapping the right way to avoid any problems later..then point the DNS of your portal (intranet.yourcompany.com) to the IP of Network Load Balancer (NLB) cluster.. and add your WFEs to the NLB cluster..thats it!
All you need,point your DNS to load balancer and add all 4 wfe,s IP to load balancer.
When user make a request it lands on lb and thenLB will fwd it to wfe(as per their policy).
I don't think u need to make any change in IIS level. Just make sure, if you have any customization I.e change in web.config or 12 hive folder, should present on all wfe.
As far Search load balancing, SharePoint control it and Most Probably Round Robin.It really does not matter on which server you configured the query component, you can configure it on WFE or on a dedicated server.
So If you have 4 Query Component on 4 wfe and only 2 WFE in LB, even then, SharePoint will route the queries on all 4 component as Round Robin( ...
As you have F5 load balancer then no reason for the NLB. There is no requirement to use the NLB.
It is rarely recommended to use the NLB rather everyone prefer the hardware Loadbalancer (i.e. F5).
Good article for understanding: http://www.collabshow.com/2009/04/16/deciding-between-nlb-vs-hardware-load-balancing/
from the image clearly the Antimalware Software is causing the issue on the server. You have to make sure that antivirus exclusion properly implemented on the server. Check this
For loadbalancing, its depend upon you load balancer settings. If it detect high CPU and take the server from LB then you will not see the issue with routine work.
I would go with custom min role as you have two Sharepoint servers, with custom role you will get options to enable or disable the service you want to.
I am not sure which service application you want to use in you farm, but you can check this link if any other minrole is good for you.
1) Yes, with the exception of the User Profile Synchronization Service, if you choose to use it. It may only run on one server in the farm per User Profile Service Application (likely you'll only have one).
2) SharePoint has an internal round-robin load balancer. All you need to do is start the appropriate Service Instances.
3) Yep, that's how it works.
Set web application's AAM settings like these:
Internal URL: https://FQDN, Public URL for Zone: https://FQDN
Internal URL: http://SERVER, Public URL for Zone: https://FQDN
Here, FQDN is external url for SharePoint, SERVER is internal. Might be the same.
Also one might want to take a look at The final guide to Alternate ...
Microsoft does not recommend these types of architecture ("stretched" farm).
Check this links:
You can use azure blob ...
If you can browse other web applications on the server except the http://web01 then looks like something wrong with the IIS Bindings.
Please make sure
IIS Bindings for the web app in place
If using the SSL, make sure SSL bindings & Certs attach to the web app.
another possibility is AV causing the issue, try to disable it.
Have you looked at Flake ? I imagine distributed sequential ID generation to be a very complex subject. I'm almost sure you won't get an implementation that is robust and returns perfectly sequential id's. In Flake's case, client's can generate the ID's themselves but they use timeslots / ranges, so they are not perfectly sequential (e.g. the number will ...
You'll need both to give the highest level of uptime.
SharePoint Request Management will ensure the request lands up at the best server within the farm to handle the request. If a server is down then Request Management will not send the request to that server and so on. All this only kicks in once the request lands up in the farm via your front end ...
The NLB "heartbeat" is just broadcast TCP/IP packets over the network, so it doesn't really check for actual availability of the site or services.
If you require a more complex heartbeat you'll have to look into other load balancing solutions. I'm no expert on it but you have F5, Cisco and other hardware load balancers that will allow you to do this.