If you find yourself running into problems with your SharePoint server when it comes to Timer Jobs, perhaps you should take the advice of Randall Monroe…
Note that I’m not actually recommending that you do this, but there’s something to be said about clearing your paging file from time to time with a reboot.
Recently I stumbled upon a SharePoint 2010 environment setup a long time ago where the managed accounts and accounts in general were setup a little funny… in particular the issue was that the profile service stopped syncing. I asked the administrator what the issue was and they stated that they’d setup the system to use a managed account for the farm service account and other service application service accounts to automatically change the password in the background. That’s all fine and dandy for the most part, ‘cept that there are caveats with the Farm Account. And low and behold, I checked and sure enough the system’s Farm account was setup now as a Managed Account in our trusty, friendly SharePoint 2010 instance.
Issue – the profile synchronization service runs as this service account. Caveat, profile sync requires that you enter the account information and credentials since you may not necessarily be sync’ing with the Active Directory resource forest that your SharePoint system leverages as its Windows Networking Infrastructure platform.
So how did we attempt to remedy this… not knowing the Farm password, it was updated in Active Directory and then using Set-SPManagedAccount with the -UseExistingPassword argument, the password was properly updated. It was then synchronized across the farm with Repair-SPManagedAccountDeployment.
So SharePoint should now be up and operational with the managed account password updated, but we also have to go and update the synchronization connection with the new password. All should be working and fine, crisis averted, just have to go in Central Admin and make the update there… But, what I thought would be a five minute fix… well, yeah, not so much.
Hello 503 error.
Oddly, after all of the troubleshooting it ended up being the bitness setting for the Application Pool that operates SharePoint was modified to operate in x86 emulation mode. This comes in handy when you need to run two different compilations of a DLL through IIS, but with our native 64 bit SharePoint application, this doesn’t work so well. Why does this happen though? Not certain but it would seem that several folks seem to have this problem when they’ve been running their SharePoint system with managed accounts automatically updating and then reverting back to an “unmanaged mode” so to speak where the metabase becomes corrupt and suddenly the fitness for x86 emulation is set to true.
More on running in both x86 and x64 mode is available here: http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx
So if I want to avert this, I can force the Application Pool to start in 64bit mode by adding a “bitness64” flag… this is done in the ApplicationHost.config located in
Within the Global Modules section of the ApplicationHost.config, you should search for the SharePoint14Module which should look something like this:
If you want to force your App Pool to always start without x86 emulation… then you’ll want to add the following argument of “bitness64” so that you end up with something like this:
Note you’ll have to do this for each of the Web Applications that are registered – if you choose to make this modification.
And just like that… I start the application pool and all is well. Went and updated the synchronization connection and our UPS started syncing again. Qed.
More on ApplicationHost.config available here: http://learn.iis.net/page.aspx/124/introduction-to-applicationhostconfig/
This past week, Scott Hoag and I had the privilege of presenting a session to the New York SharePoint User’s Group, hosted by Microsoft at their offices there in New York City on the Avenue of the Americas. There were a few familiar faces in the crowd such as Paul Galvin, Mary Leigh Mackie, Randi Parrish, Greg Hurlman and Jeremy Thake which made the large crowd a little less intimidating (or maybe more so to have peers evaluating us right?).
Before we presented though we had a few things to explore… such as the Apple Cube on 5th Avenue
I have to say that it was a pretty cool sight to see – the fact that the store is underground is in and of itself an interesting concept.
After a quick stop through we began wandering toward the Microsoft offices on foot… in the wrong direction… which got us caught up in remembering what it’s like to be a kid at FAO Schwarz… having never been inside the store I didn’t really know what to expect except for what I’d seen in the Smurfs movie that I saw last Fall… needless to say it was pretty crazy to see all of the candy and Gummi bears (oh and the nerds) as well as every popular toy that you could imagine from Star Wars apparel and masks to Thundercats action figures to even BatMan in Lego form.
All well worth the time spent in New York City, but for those that happen to be looking for a copy of our presentation, you can find it here through SlideShare.
If you need a copy to go offline with, you can grab a copy here – Avoiding Administrator Blunders in PPTX format.
SharePoint 2010 – Avoiding Administrator Blunders
So you’ve deployed an updated solution to your SharePoint 2007 or 2010 farm and you need to recycle the application pool associated with the web application that the solution is deployed to but you don’t want to take down the entire SharePoint farm? No problem, just recycle the single application pool that’s associated with that web application using a quick little command from command shell.
For those running SharePoint 2007 on Windows Server 2003 / 2003 R2:
cscript c:windowssystem32iisapp.vbs /a "%SharePointApplicationPool%" /r
where %SharePointApplicationPool% is the application pool that needs to be recycled. Note that iisapp.vbs resides within %systemroot%system32
For those running SharePoint 2007 or SharePoint 2010 on Windows Server 2008 / 2008 R2:
appcmd recycle apppool /apppool.name:%SharePointApplicationPool%
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
where %SharePointApplicationPool% is the application pool that needs to be recycled. Note that appcmd resides within %systemroot%system32inetsrv
The alternative for this of course is just to go in IIS Manager 6 or 7, select the application pool associated with the web application that requires recycling and recycle the pool manually through the UI.
References:
Are you ever working on a server and you wander away for a few minutes only to come back and find that you’ve been disconnected and your session terminated? Never something fun to work through, especially if you’re installing and configuring a software product.
In most enterprise settings this is something that you’d find in a global policy object enforcing a particular amount of time that you’re able to be Idle prior to being booted from the server. Also there’s another setting regarding the maximum connection timeout – basically how long until your session gets trashed because you decided after you’d been booted for being idle you weren’t going to log back in.
If you’re searching around for these settings, they can be found through your friendly neighborhood group policy object at:
Console RootLocal Computer PolicyComputer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop SessionSession Time Limits
Specifically you’re looking to see what the settings for the following policies are:
While they may all seem friendly, upon closer examination you’re likely to find that one of these policies is your culprit (more than like the second and third in conjunction with the fourth).
However, oddly enough some folks still use security templates to tighten the policies on their servers. In which case, there’s also a Registry edit required and a reboot. Note you should always backup your registry before you make any changes – not for the squeamish of heart.
You’ll find this information along with other helpful information for allowing and disallowing things like the use of the Clipboard (fDisableClip) in the registry branch of:
ComputerHKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTTerminal Services
Note that it’s still called Windows NT and also Terminal Services – I guess that some things never change 🙂
Specifically you’re looking for the following registry strings to modify:
The decimal values that correspond to these are counted in milliseconds. For instance, if the MaxDisconnectionTime is set to 300000, this corresponds to 5 minutes (60 seconds/minute x 1000 milliseconds/second x 5 minutes). If you don’t want to be disconnected or have a max idle time, just set the value to 0 and you’ll be all set.
Happy Implementing!
And if you’re wondering where the title for this blog post came from, check out the Fireside Theater’s “We’re All Bozos On This Bus” radio show. Has something similar where the robot gets unplugged 🙂
One of the new capabilities of SharePoint 2010 that comes in handy is the Health Monitoring alerts that pop up on the front page of Central Admin. One thing you might run into is when you start to run out of disk space. You’ll probably see something similar to this:
Always something that you want to see while you’re working on your environment right? Not so much.
For some reason it always seems that just when things are going well, profiles are synchronizing, users are starting to engage the SharePoint platform, and boom, whammo, the file system fills up with log files, trace logs and event logs. So just a gentle reminder to examine where your log files are and consider moving them to an alternate drive than the core OS drive.
How do I do this you ask? Pretty simply…
First off, decide what your disk plan is for your SharePoint Servers – hopefully you’ve got more than just a single drive in your system, if not slap on an extra drive (either physical or virtual) for log files, or if you’ve got a SAN handy, request an extra drive on separate spindles from where your data is stored and have them zone it for your SharePoint server to be added for offloading.
Next, for your IIS logs, simply open up IIS and go to the server name (in my case SP2010WFE-01) and then in the main information pane of IIS, scroll down to Logging underneath IIS.
Locate the Directory location and modify it to the location that you’ve setup for log files, in my case I’ve added an additional drive to my SharePoint server with the logical volume “E:”
Once IIS creates the structure, you’ll want to copy over old log files from your core OS drive (C:inetpublogs) to your new location.
Next up, Trace Logs for the Unified Logging System…
Within SharePoint Central Admin, navigate to Monitoring, within Reporting select “Configure Diagnostic Logging”.
Direct Link – http://<NetBiosNameOfSharePointServer>:<CentralAdminPort>/_admin/metrics.aspx
Scroll down to the Trace Log section where you’ll see something like this:
Simply input the drive that you’d prefer to use, in my case replacing %CommonProgramFiles% with “E:Program Filescommon files”, and you end up with something like this:
Go ahead and copy over the contents of the Logs file on the original instance to the new instance to consolidate your log files.
Lastly, moving your event logs to the log drive is definitely a consideration to make – especially the Security Log file as this will grow quickly once you’ve implemented Kerberos and opened your system to your user base (NTLM spawns quite a few security events too). Out of the box you’ll see your event logs like this:
Application Event Logs
Security Event Logs
System Event Logs
Simply modify the “File” location to the new location where you are looking to store your files, in my case I use “E:Windows EventsLogs” as the directory followed by the appropriate event log file name. This is documented in: http://support.microsoft.com/kb/216169
Further, to ensure that log files don’t explode, leverage the “AutoBackupLogFiles” property within the Application Events (you’ll have to add this to the Security and System Event Logs, simple DWORD property). Setting the value to “1” or any value other than “0” will create backup files in the file location specified.
This is documented in http://support.microsoft.com/kb/312571 (though it’s specific to 2000/2003 server, it works for 2008).
These three simple changes should assist in keeping your core OS drive lighter weight and prevent your system from a hiccup caused by a disk filling up.
Microsoft has released the SharePoint 2007 December 2009 Cumulative Update as of 29 January 2010. The cumulative update like all other updates includes all hotfixes since the most recent Service Pack, in this case SP2.
Information pertaining to this cumulative update is available at from the Update Resource Center at:
http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx
The WSS v3 December 2009 CU infopage is available at:
http://support.microsoft.com/kb/977027
The MOSS 2007 December 2009 CU infopage is available at:
http://support.microsoft.com/kb/977026
When requesting the appropriate CUs, if you’re downloading from an x86 client machine and your environment is x64 or vice versa, please note the “Show hotfixes for all platforms and languages” text next to “Number 1”.
Some insight from Joerg Sinemus regarding the December 2009 CU:
http://blogs.msdn.com/joerg_sinemus/archive/2009/12/16/wss-and-moss-december-2009-cu.aspx
Last but not least… please remember to test all service packs, cumulative updates and hotfixes in a staging or development environment prior to implementing in your system’s production environment.
This weekend I undertook the fun of building out a medium sized farm on my personal development hardware with my trusty MSDN license that I bought for my own personal use to begin testing a few pieces of code I’ve been working on as well as to have a play ground to work through occasional architectures, web part testing and diagnosing issues. Oh, and the fact that I’ve not had the opportunity to work with Windows Server 2008 all that much, so I figured why not go ahead and build out an environment to get my hands dirty and learn the ins and outs?
So the first part to the madness that should be understood is that IIS 7 (standard for Windows Server 2008) is a lot more granular in nature than IIS 6 which is the standard web publishing application on Windows Server 2003. From even when you’re starting your installation of the Web Server role to installing the individual components, it’s far more granular and modular, and probably confusing to some administrators that are used to just clicking “IIS” from Add/Remove Program in Server 2003.
So where to begin, well, once you’ve got your Windows Server 2008 box up, operational, patched, service packed, sysprepped (if you’re using Virtuals, you end up requiring that you have different SIDs and computer names right?), IP’d and joined to a domain, the fun begins in installing just the framework prior to SharePoint.
Step 1 – Open up the Server Manager, this typically appears when you power on the server, but if not, you should be able to find it fairly easily from the start menu. Select and expand the roles label from the tree in the left pane, then select “Add Roles” from the right pane.
Step 2 – If this is your first time installing a role, this would probably be helpful to read “Before You Begin”. Definitely read through it at least once, after that, feel free to click the check box to skip it in all future instances. Click on Next.
Step 3 – Select the Web Server role from the list of server roles. Note that you will be prompted to select additional features for the Web Server role to operate properly. Select “Add Required Features” else turn and back away, and perhaps reconsider what you’re looking to do.
Step 4 – Once you’ve accepted the need for additional “required” features to be installed, you should see something like the below stating that you have selected the “Web Server (IIS)”. Click on Next.
Step 5 – The role installation wizard presents an overview of the Web Server (IIS) role which again is fairly useful for an administrator to read through the first time. Click Next.
Step 6 – Select the individual server roles that you require for your SharePoint installation. I’ve found that the basic role services that are installed with IIS 7 are barebones, which from a security posture is fairly helpful so as to not have to remove several roles, but it will make you stop and think through what roles you do indeed to make the system operational.
Step 7 – The first thing to select of course to make your platform usable by SharePoint is the ASP.NET development platform. Once you’ve selected this, you will be prompted to add additional roles that are required for ASP.NET. Select the “Add Required Role Services” else, much like before, be prepared to have a difficult time installing SharePoint services on your server.
Step 8 – Select the additional roles that will assist in your SharePoint implementation, in my case this also includes “Logging Tools” to diagnose issues that may come up.
9 – Select the appropriate authentication providers that you wish to be able to utilize. For me, I’m going with a fairly vanilla SharePoint installation and configuration, so I’ll select “Windows Authentication”.
10 – Additionally, so as to not bother with going back and installing later, I’ve selected the “IIS Management Scripts and Tools”.
11 – Lastly, the “Management Service” to be able to better manage the IIS 7 instance on the server from the server or remotely.
12 – After selecting the roles that are appropriate to support your SharePoint services installation, click on Next, which then will bring you to a page that lists all of the components that you are looking to install. Do a quick read through to ensure that you’ve got the components, roles and features that you require and click on Install.
13 – Observe the installation process as can be seen here:
14 – After a few minutes, the installation progress bar will complete and an installation results page similar to this will be presented. Click on Close after you’ve observed that your installation results were successful.
15 – After you’ve completed your IIS 7 installation, you’ll see that there are 24 installed role services related to IIS running and operational on the server through the Service Manager roles summary.
Next on Tap:
The Tech Blog of Dan Usher 