This is an interesting white paper on the performance of enabling RBS “Remote Blob Storage” with SharePoint 2010.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4ce0c906-3f71-4fff-b3f9-9462343c453f&displaylang=en

Couple of interesting exerts from the paper!

- Objectives of the test

 SQL Server database data and transaction log file sizes
 Backup file size
 Time taken to back up and restore content database
 Time taken to rebuild content database indexes
 Effects of index rebuild operation on performance of end-user transactions
 SharePoint transaction response times
 SharePoint Server search crawl operation
 File upload performance
 Consistent performance as the scale of the content increases
 Time taken to migrate data in and out of the RBS store

Time to backup the DB’s

Response times “very cool”

Checkout the load times!

Search Crawl Times

One of my favorites “File Upload Times”

Overall an amazing paper!  Great Job!

How many times have you been in an area where internet access is restricted?  For me, this is the norm.  I found both TechNet sections for SharePoint 2010 and FAST Search for SharePoint 2010 in downloadable CHM format. Basically portable TechNet.. SWEET..

Here are the links:

Microsoft SharePoint Server 2010 Technical Library in Compiled Help Format - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3629425d-1505-456e-89e2-ede95f75ffe5&displaylang=en

Microsoft FAST Search Server 2010 for SharePoint Technical Library in Compiled Help format - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ead44c66-7d02-4edf-9e56-2f56c6f59f22&DisplayLang=en

Hope this helps!

Update:

If you download the chm and notice that content is not displayed ‘shown below”, you will need to right click on the CHM, go to properties and “unblock” it.

   <—what you should see once you unblock it!

One of the most important SQL Databases with regards to SharePoint is the TEMPDB.  Most SharePoint performance issues are due to improper SQL configuration and more importantly, not giving enough thought to the tempdb itself.  In SharePoint, every action that you take is staged in the tempdb before it is committed.  Consider the tempdb a working area for SharePoint operations.  Dumping 300 list items into a SharePoint list?? Guess where the operation hits first, yep, tempdb.

So lets get to some basic recommendations that could increase your SharePoint performance by 20 to 30% or more!

1. First, move the tempdb to a separate LUN or set of high speed spindles.  I am not necessarily talking the LDF files, but more importantly the MDF files.  Move them off and keep them separate!
2. Add multiple files to your TEMPDB “called NDF files”.  SQL is a multi-threaded application and can simultaneously write to more than one file at a time so why not add some NDF files to your tempdb. 
3. Once you add multiple files, if at all possible, move those off to separate spindles too!
4. Pre-Size your tempdb files this way SQL does not incur expansion operations during large usage of SharePoint

So how many files should you have for your tempdb?  There are some basic calculations but what I always do is divide the total number of processor cores by 4.  That is a good start!

If you have a quad core, quad processor system equating to 16 core processors, you would get a total of 4 TEMPDB files.

Some would argue that dividing by 2 is the right method; using that formula, the above example would give you 8 TEMPDB files.  My recommendation is to test with 4 first, then move up because like most tweaks, they will almost eventually taper off and probably provide negative performance. 

For those of you that do not think that performing these actions will realize performance, try it – you will be surprised.  Setup up two vm’s one with SQL and one with SharePoint, and load up 1000 list items into a SharePoint list and calculate how long it takes.  Try the recommendations above, then create a new list and load those same 1000 items.  Notice the improvement??

For those of you that would like to see the SQL script to add files + presize them – I have included it below!  In the example below, I am pre-sizing the files to 20GB.  AND as with all scripts, test them in a “dev” environment please!

Hope this helps!

ALTER DATABASE [tempdb]
MODIFY FILE ( NAME = N'tempdev' , SIZE = 20480000KB )

ALTER DATABASE [tempdb]
ADD File ( NAME = N'tempdev_2', FILENAME = N'G:\SQL\TempDB2\tempDB2\tempdev_2.ndf' , SIZE = 20480000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB)

ALTER DATABASE [tempdb]
ADD File ( NAME = N'tempdev_3', FILENAME = N'G:\SQL\TempDB3\tempDB3\tempdev_3.ndf' , SIZE = 20480000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB)

ALTER DATABASE [tempdb]
ADD File ( NAME = N'tempdev_4', FILENAME = N'G:\SQL\TempDB4\tempDB4\tempdev_4.ndf' , SIZE = 20480000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB)

GO

I was working on syncing user profiles from AD into a test SharePoint 2010 instance when I ran into the infamous error  (An update conflict has occurred and you must re-try this action)

“shown below”:

What a nasty looking error!

What is the fix that worked for me??

1. stop the timer service on all your SharePoint 2010 servers
2. add the user account that will run the “User Profile Synchronization Service” to the local admins of each and ever SharePoint 2010 server
3. set both FIM services to automatic on the server that will run the service “mine was INDEX01” – NOTE, do not change the user account or try to start the service, just set it to automatic!
4. Start the timer service on all your SharePoint 2010 servers “it does not matter which order”
5. Go to Central Admin – System Settings – Manage Services on Server – select INDEX01 “or the server that will run the service” – and click Start next to User Profile Synchronization Service.
6. Wait about 5 to 10 minutes “mine took close to 10”
7. Refresh the page and you will notice that the service is started

I then removed the service account from the local admins group on each server and restarted the service “Stop / Start” from within Central Admin and everything started fine.  There is no need to leave the account in local admins.

Hope this helps someone else!

Ah yes – the question I get asked daily.. well maybe weekly.  What are the pre-requisites for SharePoint 2010?  Well the best way to explain this is to show you the screenshot of “prep” tool.  You can download them individually for air-gapped networks and script it or you can let the prep tool itself download and install them.  If you go through the process with a disconnected machine, it will show you a similar screen indicating what is needed and what was skipped.  Anyways – here is the screen shot – hope it helps someone!

Here is a screen shot of a system that already had the pre-reqs installed!

Update: A buddy of mine told me that if you install the SQL2008 R2 components instead of the SQL2008 components and run the prep tool, the precheck will fail “assuming you do not have internet access”.  If you have installed the SQL 2008 R2 components and all other components, you do not need to run the pre-check, you can run the installation directly.  The installation will detect if you are missing any requirements and direct you to run the pre-check.  I am not sure if the product team knows about this flaw in the pre-checker but it through me for a loop.

Today, I was messing around with the windows backup service and created a backup of the system state.  When I browsed to the directory I noticed that the actual backup consisted of a bunch of xml files and an actual VHD file.  I attached the vhd file using disk manager and guess what, I was able to actually see the stuff in the backup.  AWESOME – seems like a very small win but I think it’s a cool one!

Part 3 of this multipart series involves setting up TMG “Threat Management Gateway” – basically the latest version of ISA.  Before we start, there has been a ton of confusion with respect with how to setup ISA/TMG’s network cards.  Assume we have 2 NICs (we are not network load balancing), NIC1 being External and NIC2 being Internal.

If you are wondering why I chose to setup TMG in this fashion – read the following posts:

http://blog.msfirewall.org.uk/2008/06/isa-servers-recommeded-network-card.html

http://www.kalabaster.com/dasblog/2009/09/06/ISAServerAndFTMGBasicNetworkAndDNSSettingsOnceAndForAll.aspx

Internal NIC Screenshots (Part of AD Domain: NA.LOCAL)	External NIC Screenshots

The TMG server that I am working with will be part of the Active Directory (NA.LOCAL) that we setup in Part 2.

Let the install begin!!!

(To conserve Page Space – I have posted the steps to follow a “Z” pattern, for example, A 4 Step process would have step 1 in the top left quadrant, step 2 in the top right quadrant, step 3 in the bottom left quadrant, and step 4 in the bottom right quadrant)

Click “Run Installation Wizard”	Another couple windows will pop up..
Click Next	Click “I Accept” then Click Next
Type your information / key code, click Next	Select “TMG Services & MGMT” click Next
Browse to a custom install path if needed, click Next	Click Add to define Internal Network
Click Add Adapter on the following screen	Select your Internal Adapter, click OK
In my case, I picked the “Internal Adapter” which produced the following screenshot:	We do not need all of those ranges – we only need the range that the internal NIC is configured to be a part of.  The range should read: 10.1.1.0 – 10.1.1.255 To remove the ranges, highlight each one and the “remove” button will activate.  Now that you have a blank Start Address / End Address screen, go to the next step.
Click Add Range, type your internal SUBNET, click OK	Once the range looks correct, click OK
Verify Internal Network Address, click Next	Click Next
Click Install	This will take several minutes Window
Estimated Time Window	Installation Complete, click Finish

Now that you have TMG setup – you will notice that the TMG server itself cannot access the internet.  If you go to any of the internal server (servers on the internal network of TMG – 10.1.1.0/24 in my lab) they also cannot access the internet.  Why is this happening?  The reason that you cannot access the internet is because all systems, including TMG, are using the Domain Controller, 10.1.1.10 for DNS lookups.  The domain controller will use root hints to resolve DNS Lookups.  Remember, TMG is a firewall, so we have to allow that type of traffic from internal servers out to the external world through TMG.  More specifically, we have to at least create an ACCESS RULE allowing the Domain Controller the ability to perform DNS Lookups.  Since all machines on the internal network have the Default Gateway pointing to the internal NIC of TMG, TMG is currently blocking that traffic.  HTTP access is not blocked from internal to external since we set that up already, its DNS that is being blocked.

How the heck do I know this? – The LOGS speak for themselves. 

Open up the Forefront TMG Console, click on Logs & Reports, click on Start Query (This will show you all traffic since we did not modify the filter, but that’s ok!

Connect to an internal server (I will connect to my Domain Controller for now), open up a web browser and visit any website.  Example: www.bing.com

Immediately after, go back to the TMG Console and click on Stop Query under the Logs & Reports screen.  At this point, you can search for the denied packets.  See below -

  You see that the Domain Controller – 10.1.1.10 was denied outward on port 53.  Port 53 = DNS.

So, lets fix it – Lets create a rule that allows internal servers the ability to perform outbound DNS Lookups.

Now that we have added a rule for DNS lookups to be allowed outbound from the internal network, we can check internet access again.  Before we check access, lets turn on logging as we did before to see the “allowed” packets destined for port 53 “DNS”.

Open up the Forefront TMG Console, click on Logs & Reports, click on Start Query (This will show you all traffic since we did not modify the filter, but that’s ok!

Connect to an internal server (I will connect to my Domain Controller for now), open up a web browser and visit any website.  Example: www.bing.com

Immediately after, go back to the TMG Console and click on Stop Query under the Logs & Reports screen.  At this point, you can search for the denied packets.  See below -

  Status: The Operations was completed successfully.  Rule: OUTBOUND_DNS

If you look a little further in the log, you will notice the allowed HTTP connection to www.bing.com

SUCCESS!!! – You now have a completed the installation of Forefront TMG Edge Firewall!!

First things first – We have to install a Domain Controller.  This DC will be Windows 2008 R2!  It will be the only DC within this environment.

The Domain FQDN will be: NA.LOCAL 

Here are the steps: (Some things to note: I have already configured the server with a static IP Address – the settings are below)

IP Settings =  Adv TCPIP Settings = 

• Add the Active Directory Domain Services Role by starting Server Manager, clicking on Roles, then Add Roles
  • 
  • Adding the AD role will require .NET Framework to be installed – this happens automatically so do not worry
  • You do not have to add the DNS role at this time either – when you go through the DCPROMO setup, it will add the DNS role for you.
  • Once the AD role is added, now you can run DCPROMO (In earlier versions of Windows – you would just run DCPROMO)
• Click Start, and type DCPROMO, hit enter
  • 
  • This will start the DCPROMO Wizard
• Click Advanced Mode, then click Next
  • 
• Click Next
  • 
• Click “Create a new domain in a new forest”, then click Next
  • 
• Type the FQDN of your new domain, then click Next (I will use NA.LOCAL for the VDI / RDS environment)
  • 
• Click Next on the Domain NETBIOS Name (my domain NETBIOS name is NA)
  • 
• Pick Windows 2008 R2 as the domain functional level, then click next
  • 
• The wizard will detect that this is the first DC in the new Forest root and it will prompt you to install DNS and automatically make this DC a GC “Global Catalog”.  Click Next
  • 
• You will receive a warning about DNS – you can ignore it and click YES since this is a standalone root forest for the purposes of testing VDI / RDS.
  • 
• The next screen will allow you the ability to change the location of the AD files, NTDS, Log files, etc etc.  Since this is a lab, there is no need to change anything.  Click Next…
  • 
• Type an Active Directory Restore Password twice, then click Next
  • 
• Verify that the settings are correct, then click Next
  •  

At this point, the wizard will begin to install Active Directory Services.  If you followed the instructions step by step, you should receive no error messages.  If you are wondering why I actually issued a Default Gateway of 10.1.1.1, it is because that address will be issued to our TMG server “aka ISA”.  This entire network will be protected via TMG “Threat Management Gateway”, the newest version of ISA.  I will make the TMG server part of the Active Directory Domain NA.LOCAL. 

• If all went well – the message you will receive will look like the following…
• Click Finish
• Click Restart
  • 

In Part 3 of this series – I will cover the installation of TMG!

NOTE: This post is not completed.. to be continued…

Although Part 1 is not complete – Part 2 is… click HERE for Part 2 of this post….

I have attached a txt file with the code.

Usage example:

cscript PINGSubnet.vbs /IP:1.2.3.4 /mask:255.255.255.0 /ping

Where:
/IP: specifies a valid IP address and MUST be supplied.
/mask: specifies a valid subnet mask and MUST be supplied
/ping is optional. If supplied, every host in the subnet will be pinged, and res
ult shown.

Most invalid subnet masks will be flagged as such and the script will end.
There is no checking for valid IP address yet!

pinger.txt