Archive for the ‘Terry Engelstad’ Category

« PREVIOUS

Congratulations to Terry Engelstad!

January 22nd, 2013
Posted by: Kurt Baumann

By Kurt Baumann
AIS Network Chairman and CTO

Today, we announced the promotion of Terry Engelstad to the position of VP of Network Operations.  It’s a much deserved promotion, as Terry has been such an important part of all our recent growth.  Terry started with AISN in 2007 and has since helped us double our network.  And we are on path to do that again this year.http://www.aisn.net/wp-admin/post.php?post=3025&action=edit

With Terry, AISN has gained not only over 20 additional certifications in Microsoft, Cisco and Oracle, but also over 2 decades of network and software engineering experience.  Terry’s leadership has also helped us expand into new locations (Virginia) and new markets including our Virginia eGov initiative which has been very fruitful for the company.

Interesting tidbit: Terry, who is a born and bred Chicagoan, actually was a professional soccer player and played with the Chicago Mustangs.

Find out more about Terry on his bio or read our press release here.

 

TAGS:

CATEGORIES:

No Comments »

Cleaning Out the SharePoint Site Recycle Bin

July 16th, 2012
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

Recently, a SharePoint hosting customer asked us to perform routine maintenance on his SharePoint site.  As part of that, he asked us to clean out the Recycle Bin and have the automatic deletion mechanism disabled for the Recycle Bin.  He said that his company hadn’t cleaned its SharePoint Recycle Bin in over one year.

There are some things you might find interesting about the Recycle Bin, which is the first line of defense in recovering data. As you probably know, SharePoint uses a two-tier Recycle Bin. The first tier is at the User level where an item deleted from a List or Library will drop into the User Recycle Bin. This way, the Users can recover deleted items themselves. Then after a period of time, items will be moved from the User Recycle Bin to a Site Collection Recycle Bin. The duration for which an item sits in the User Recycle Bin is determined by a parameter in SharePoint Central and is specific to an entire Web Application.  The duration for which items will sit in the Site Collection Recycle Bin is determined by the amount of space available to hold these items and is also configurable via a parameter in SharePoint Central.

Currently, our customer’s User Recycle Bin is configured to never delete items.  There are quite a few items in various User Recycle Bins. There are two ways to clean them out.  First, somebody can go to each of the User Recycle Bins and remove items manually.  Or, second, the retention configuration parameter could be changed to a very low value, and after a period of time, the items will flush out on their own.

The difference between these two techniques is that the first one requires human intervention to find all the Recycle Bins and to make decisions about which items should be deleted or not. The second option is global and will affect all items in all Recycle Bins.

Naturally, if our client wants us to clean out the User Recycle Bins individually, they would also need to define the rules for deletion of those items (i.e., delete everything older than 30 days, for example).

On the other hand, if the customer wants us to change the configuration parameters, we’d be happy to do so.  That’s easy.

More questions about your hosted SharePoint?  Leave your comments below.

TAGS:

CATEGORIES:

10 Comments »

Slow SharePoint Server? If your SharePoint Loads Slowly, This May Be Why.

July 9th, 2012
Posted by: admin

 

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

Is your SharePoint Server running slow?

Recently, a client emailed to say that he was noticing large slowdowns in connecting to their SharePoint server at AISN.  It seems to be happening nightly and intermittently throughout the day, he said.  Specifically, his issues were:

  1. SharePoint content loads slowly
  2. Uploading/ downloading from SharePoint is impossible (speeds come to a crawl at less than 5KBps)
  3. Remoting in to the SharePoint server is very slow

He asked what could be causing a slow SharePoint Server and SharePoint SQL Server.  Here’s the problem in his case.

The servers, in general, are starving for memory.  The hypervisor on which they reside (XYZ1) has only 74 MB of free memory.  Microsoft recommends not dropping below 2 GB of free memory on a hypervisor.

See the image below for XYZ1 (real names changed to protect client).

Slow SharePoint

As I explained to our client, the server “SharePoint” has 0 free memory and is warning that it needs more.  It looks like the vast majority of the memory on SharePoint is being consumed by w3wp.exe – IIS Application Pools. This would certainly contribute to slow web page rendering.  And with 0 free memory, anybody who remotes into it will take more memory away from the Application Pools, thereby making it slower.

In our client’s case, the server “SharePointSQL” is grossly overtaxed.  I count 68 databases defined and live.  This is way, way too much for a SQL Server with only 8 GB of memory.  The Microsoft recommendation is 8 GB of memory for a lightly used SharePoint Foundation Farm and 16 GB for a lightly used SharePoint Server Farm.

This level of memory, combined with the number of databases, will create very small page caching (perhaps not even caching at all).  This will seriously degrade the speed of uploading documents.

As you may or may not know, SharePoint stores all documents as Binary Large Objects (BLOBs).  In order to properly convert, for example, a Word document to a BLOB, it must cache the entire uploaded document somewhere before it can go through the conversion to a BLOB. So again, small or non-existent cache, means real slow upload and download times, among other slownesses.

In this case, adding more memory is the solution to a slow SharePoint Server.   However, a SharePoint private cloud would be an ideal approach – one that allows for the flexibility and scalability this client needs to accommodate growth smoothly.

TAGS:

CATEGORIES:

3 Comments »

SQL Server Virtualization and Why It May Not Be a Good Idea

April 19th, 2012
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

It’s very tempting to move Microsoft SQL Server instances to a virtualized environment, especially now that virtualization has become more sophisticated.

Theoretically, reducing the number of physical machines that you have while saving money by cutting your power, maintenance and licensing costs, may seem like the way to go.  But, in a production environment, why may virtualizing a SQL Server not always be a good idea?

The problem is not the hypervisor.  The problem is not the big, fast disk.  The problem is resource contention.  All database management systems work better when you give them their own resources.  More memory, more central processing unit (CPU), more disk – it doesn’t matter.  The bottom line is:  Just throw dedicated resources at a database management system (DBMS) and it will work better.   While the virtual machines (VMs) run very well, there is likely going to be a noticeable difference between a VM and a physical machine.

The problem with virtualizing a DBMS goes to the very purpose of virtualization – attempting to reduce resources in order to reduce costs.  The main retort from both Microsoft and VMWare about getting around reducing resources is that they have built in the ability to “share” resources – sharing CPU, sharing memory, sharing disk.  Herein is the problem for databases.  They don’t play nicely in the sandbox.  They don’t share well.  They want their own resources.

So, what do you do?  Well, first understand the limits of virtualization and choose your virtualization instances wisely.  Remember, there is no absolute solution to virtualizing SQL Server.  The best you can hope for is a compromise.  And the best way to compromise is to continue to try to isolate SQL Server instances.  Over-allocating resources (CPU, memory, disk) in a contentious situation will make an already bad situation worse, so don’t over allocate.  In short, don’t fall for “shared resources.”

TAGS:

CATEGORIES:

1 Comment »

Virtual or Physical? Data Storage Configurations Using SQL Server

April 3rd, 2012
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

On a data storage configuration project involving Microsoft SQL Server, a colleague asked me:

We need 700GB of storage, which must be expandable by 10X.  We will be using Metalogix to externalize the 700GB of content.  Metalogix puts markers in SQL pointing to the storage.  Since the data is not actually residing in SQL, can we virtualize the Web front end (WFE), app server, and SQL server, and have the storage be in the AIS Network storage area network (SAN)?

Well, SQL Server 2008 introduced a feature called FileStream. This feature allows SQL Server to store data in an unstructured format outside of the database management system in the file system of the underlying operating system.

Data storage AIS Network

Data storage configurations require thoughtful planning.

This feature is generally used only when the objects which SQL Server needs to access are 1) huge and 2) need very fast READ access.

FileStream puts these objects in the file system just as you would save a Word document.  By doing so, the same set of problems exists as if these files were Word documents on your own hard drive.  They must be backed up separately from the databases.  They can be deleted either accidentally or intentionally.  They are exposed to disk corruption just as any other file would be.  Unless encrypted, their contents are viewable.

So to answer the question, yes, the data could be virtualized.  After all, it’s just files on a hard disk.  Is there an expectation of high performance?  700 GB (or 10 x 700 GB) far exceeds my heuristic, which says it should be physical, not virtual.  Therefore, the fact that it is externalized does not change my recommendation that it be a physical machine.

The follow-up question was:

Can we have a virtual machine (VM) WFE, VM app server, physical SQL server, with storage in the SAN?  If so, what size drive do we need in the SQL server?

The fact that data is stored externally really doesn’t matter.  My concern is the amount of activity going back and forth thru a virtualized environment.  If there are a lot of reads, a lot of writes, or a lot of both, then that’s a lot of traffic which could potentially affect other virtual machines  in the environment.

So, yes, you can have a VM WFE, a VM app server, and a physical SQL server with storage in a SAN.  This is exactly what one of our clients has.  The physical SQL server would need enough disk space for the operating system and supporting application software – probably no more than 120 GB, and perhaps less. The drives on the SAN would get mapped to the physical server and would be connected directly via fiber optic cabling (very good performance, no startup problems) or via iSCSI (using copper Ethernet cables with possibly delayed start).

What configurations work for you?  Let me hear from you below.

TAGS:

CATEGORIES:

3 Comments »

SharePoint and SQL Server: Give It Memory

March 15th, 2012
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

If you are not familiar with how SQL Server works, you should know that it does, in fact, use memory for caching of data.  If you don’t give it enough memory, then it won’t cache enough data.  If you don’t cache enough of the right data, then you must go to disk to get it.  If you have to go to disk to get it, then you are making excessive trips to the SAN to retrieve data, thereby reducing the overall efficiency to everybody on the SAN.

I’ve done a couple hundred installations of SharePoint, and I am definitely a believer in “more is better.”   When it comes to SharePoint, you absolutely must give it memory – and lots of it.  You cannot get away with shorting memory and disk space.

If you really want to tick off a customer, take a SharePoint Site that has a reasonable amount of traffic and start reducing the amount of memory SQL Server has to work with.  See how long it takes for that customer to start complaining.  It won’t take long.

 

TAGS:

CATEGORIES:

2 Comments »

SharePoint 2010: Loopback Checking

March 1st, 2012
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

There is a security feature in Windows 2008 called Loopback Checking.  It’s a security feature in IIS, which is a way of stopping some denial of service attacks.  Since SharePoint 2010 runs locally on the server, and accesses its own databases by way of Communication Foundation service calls through IIS, technically, SharePoint is performing what could be construed as a self-denial-of-service-attack.  There is a registry hack to turn off the feature.

This feature is only an issue on servers which are domain controllers and running SharePoint and SQL Server at the same time.  Loopback Checking is not a problem on servers which are not domain controllers, nor in multi-server farm scenarios where SQL Server is not running on the same server as IIS.

For more information about disabling the loopback check, see Microsoft Support Article 896861.

TAGS:

CATEGORIES:

6 Comments »

SharePoint Migrations: How Long Does a Migration and Upgrade to SharePoint 2010 Take?

December 1st, 2011
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

Recently, a visitor to our Web site asked an excellent question.  How long does a migration and upgrade from SharePoint 2007 to SharePoint 2010 take?  The answer to this question is very complex and depends on a number factors.  The subject is much more complex than can be explained in a mere couple of paragraphs but here’s a very brief response.

SharePoint Migration AIS Network

It's important to understand that a migration to SharePoint 2010 may take some time.

First of all, his question is not about just a migration.  It is about a migration and an upgrade.  The answer depends on the following:

1)  There are at least three different ways to migrate and upgrade SharePoint sites:

  • Site by site
  • Database detach/re-attach
  • In-place upgrade

2)  The size of the databases involved is huge in determining the duration.

3)  The type of documents in Content.

4) What customizations have been enabled in the SharePoint 2007 implementation? Some may not “migrate.”

5)  The speed of the server(s) involved.

As a point of reference, we recently did a migration and upgrade to SharePoint 2010 for a client.  It took approximately four weeks to plan, test, and finally do the deed.  The actual migration/upgrade took approximately 24 hours.  This client has a 100 GB Content database and they did a database detach/re-attach and then an in-place upgrade. The only customizations that they made in their 2007 environment were to the visual theme, which did not migrate (it’s a known issue).

For those of you who are planning a migration, we’d be interested in hearing more of your questions.

TAGS:

CATEGORIES:

3 Comments »

SharePoint 2010 Disaster Recovery: Failover Scenarios

September 22nd, 2011
Posted by: admin

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

I recently published a blog post entitled, “SharePoint and Disaster Recovery Options,” but it did not specifically address SharePoint failover scenarios.

I began to give more thought to failover scenarios when a prospective customer asked us to devise a SharePoint environment that has the option for a fully redundant, geographically dispersed disaster recovery plan.  After being asked to break out the cost for a direct failover time of a few seconds, 15 minutes and 4 hours, I was asked about our options to accommodate the few seconds, 15 minutes and 4 hours with no data loss incurred.

Failover of SharePoint is implemented differently depending on which version of SharePoint and SQL Server a client is using.  There are usually two components to “recovery” – RTO (Recovery Time Objective) and RPO (Recovery Point-in-Time Objective).  RTO is how long does it take to recover.  RPO is what point-in-time do you want to recover to.

Breaking out the cost pertains only to RTO.   However, the second question, regarding options to accommodate time lapses, also needs to be considered and is probably more important in determining a solution than RTO.   If your RPO is “recovery with no loss,” then the only solution is to use SQL Server Enterprise Edition with multi-threaded Mirroring enabled.

The failover dilemma with SharePoint 2010 is that there are many more databases than in previous editions. For example, in MOSS, fully implemented, there are only four databases. In WSS 3.0, there are only three databases. In SharePoint Foundation 2010, there are 12 databases. In a SharePoint Server 2010 bare-bones installation, there are 22 databases.

The number of databases in SharePoint 2010 is directly tied to the number of features which get implemented. If, for example, Excel Service gets implemented, then that’s another database. If Access Services gets implemented, then that’s another database. That said, you could get away with doing Log Shipping in previous versions, but with SharePoint 2010, it is a royal pain in the butt.  Each database needs a separate Log Shipping configuration. However, some of the databases will not recover properly with Log Shipping, because they are tied to SharePoint’s always-running Timer activity.

That said, here are my recommendations assuming RPO is immediate (i.e., no data loss):

For recovery in a few seconds:

-          SQL Server Enterprise Edition with multi-threaded Mirroring implemented

For recovery in 15 minutes:

-          SQL Server Enterprise Edition with multi-threaded Mirroring implemented

For recovery in 4 hours:

-          SQL Server Enterprise Edition with multi-threaded Mirroring implemented

As I mentioned in my previous blog, the SharePoint 2010 Disaster Recovery Guide by John L. Ferringer and Sean P. McDonough is a good resource.  I would be interested in your thoughts on this too.  Leave a comment, please.

TAGS:

CATEGORIES:

19 Comments »

SharePoint and Disaster Recovery Options

August 23rd, 2011
Posted by: admin

AIS Network Blog SharePoint 2010 Disaster Recovery

The SharePoint 2010 Disaster Recovery Guide.

By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager

The complexity and diversity of the Microsoft SharePoint platform also applies to its disaster recovery options.  When it comes to protecting your SharePoint farm from the effects of a catastrophic event, there are numerous tools and best practices.  But which is the best fit for you?

I recently completed reading and studying the SharePoint 2010 Disaster Recovery Guide by John L. Ferringer and Sean P. McDonough.  It’s a worthwhile read, if you have the opportunity and particularly if you are trying to determine whether your current procedure for backing up SharePoint environments provides adequate and proper recovery capabilities.

The book explains that there are three kinds of recoveries:

-          Content

-          Site Collection

-          Full Farm

If you need to do Content recovery, then the Content Database needs to be backed up. If you need to recover a Site Collection, then the Site Collection needs to be backed up. Content is backed up as part of a Site Collection, but a Site Collection is not backed up as part of Content. If you need to recover a full farm, then you need to do a Full Farm backup. Merely backing up the individual SQL Server databases does not capture enough information to recover a full farm. There are additional components that get installed on the server; these are not in a SQL Server database and therefore will not be available for a recovery.

This means that if your current procedure is to back up the SQL Server databases, then that method will not work for Full Farm recovery of SP 2010 Foundation or Server. According to Microsoft, this is an un-supported practice, which means you may get lucky and it might work, but then again, maybe not.

The only fully supported method for a full farm recovery is to do SharePoint Full Farm Backups. SharePoint Full Farm Backups are executed via:

1) SharePoint Central GUI,

2) PowerShell commands, or

3) stsadm command line.

Execution via PowerShell or stsadm can be scripted as batch jobs and scheduled. A full farm backup ends up including the SQL Server databases, but it also picks up the IIS configuration, the Hive, GAC components, and Customized Code – everything required for Full Farm Recovery.

In some circumstances, there may be a difference in the amount of space and time used to create a Full Farm Backup. FFB creates an un-compressed, directory structure, which would subsequently be backed up to storage for 14-day (or otherwise) retention. The “un-compressed” part will not be affected by those implementations using SQL Server Web Edition, since Web Edition doesn’t compress backups. For those implementations using SQL Standard or SQL Enterprise, this would result in additional disk space being consumed, because what was once compressed will no longer be compressed.

How are you approaching SharePoint 2010 disaster recovery?  I encourage your comments.

TAGS:

CATEGORIES:

17 Comments »

« Older Entries