Skip Ribbon Commands
Skip to main content

Quick Launch
Home > Blog
The ramblings of a generic SharePoint Consultant Developer
January 22
UPA Persistent Stuck on Starting Issue
by  System Account  on 22/01/2012 16:32

The UPA Stuck on Starting journey – a trip into FIM hell!

There are many great articles that list various steps to clear "stuck on starting" in FIM – including the defacto bible of Stuck on Starting by Spence Harber:

http://www.harbar.net/articles/sp2010ups2.aspx

However in certain circumstances the usual steps of clearing this issue don't always work.

Recently I had an issue where an OOTB SharePoint 2010 farm (No service packs or CUs applied) had un-provisioned itself.

When trying to re-provision, the one off timer job that does this did not materialise and I was left in a state of "Stuck on Starting" but with no timer job, all services stopped and the application online. This became very frustrating and no matter what I tried I could not get rid of the "Starting" state.

To rectify this I used the following method in this order:

Customer was using OOTB sharepoint config – with a named SQL instance so by default the service would not re-provision until the June CU or a hot fix was applied (see here for error details)– in this case the customer was not ready to go to sp1 so the hotfixes had to be applied:

After this is noticed the "Starting" was still persistent in mange services on server and when trying to start the FIM services manually - I got a slew of errors - Eventids: 22, 3, 26, 2, 3 :

Running though the normal steps to clear this issue did not remediate it. Im going to list the steps here for brevity as in most cases they would of worked:

  • Stop User profile service and User profile sync service on ALL SharePoint servers in the farm
  • Clear timer config cache by following the "resolution" documented at http://support.microsoft.com/kb/939308
  • Deleted the Pending timer job related to the UPA sync service provisioning using Central administration->Monitoring->check job status
  • Confirmed that the security token service has only windows and anonymous enabled ( from IIS manager->SharePoint web services->Security token service->Authentication (under IIS))
  • On the SharePoint server access the registry editor and confirm that the information related to FIM ( database servername , sync DB name etc ) are properly populated, if found wrong , back up the registry key and edit the values to reflect the right information.
  • HKLM\system\currentcontrolset001\services\FIMservice
  • HKLM\system\currentcontrolset002\services\FIMservice
  • HKLM\system\currentcontrolset\services\FIMservice
  • Delete all FIM related certificates from certificate store ( for account and system) . Make sure that no FIM related certificate is listed in any folders when looked at certificate manager.
  • From Central administration->Application management->Manage service application, Make sure the User profile service application and its proxy are started, If found stopped, its always recommended to recreate them taking necessary backups (mysites)
  • Start User profile service on the machine where you would like to start the User profile sync service (use central administration console)
  • Once the service is started, try starting the User profile sync service from the central administration site

So as you can see there were quite a few steps without success.

If you use the Get/Stop SPService instance you will be able to see the state SP thinks the UPA service is in. In this case there were 3 three UPA services, 2 of them stopped, but one of the them was "Stuck" in provisioning!

In the SP2010 command shell use the following command to list them:

get-SPServiceInstance | where {$_.TypeName -like "*User*"}

If you see an instance that is "Provisioning" you will need to stop it as it is this that is causing the issue:

Stop-SPServiceInstance -identity <GUID>

They should all now be disabled:

Success! You should note now that the service should be registered as stopped in the interface:

For good measure at this point I turned Verbose logging on for UPA (don't forget to turn it off when you're done). I then started ULS viewer and filtered category on "User Profiles" which helps to track the actual provisioning process so you can view errors as they occur.

Start User Profile Service through the interface as normal

You should be able to watch the process provisioning in its entirety (usually takes around 15 minutes)

Success!

I then went and recreated and my synchronisation connections and performed a full sync

Hope you find this useful!

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
December 21
Error deploying administration application pool credentials
by  System Account  on 21/12/2011 13:03

​When trying to change administrative credentials using the manage accounts interface in SharePoint 2010 I often come across this error:

 

Error deploying administration application pool credentials. Another deployment may be active. An object of the type Microsoft.SharePoint.Administration.SPAdminAppPoolCredentialDeploymentJobDefinition named "job-admin-apppool-change" already exists under the parent Microsoft.SharePoint.Administration.SPTimerService named "SPTimerV4".  Rename your object or delete the existing object.

 

When the managed accounts tab section is used to change the password it creates a timer job "job-admin-apppool-change" and if this is half way or has been corrupted (like its been half way through and system reboot occurred) then the job “Sticks” and this can manifest itself as the error above.

The best and quickest way of rectifying this I have found is to delete the job and try again.

Use the following PowerShell to delete the job:

 

$tj = Get-SPTimerJob -Identity "job-admin-apppool-change"

$TJ.Delete()

 

Now try reset your password again using the managed accounts link and you should be successful

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
September 12
User Display Name Set to Domain\Username – SharePoint 2010
by  System Account  on 12/09/2011 16:41

In truth this error can be caused by a number of factors and there is not just one answer. The best way to approach this error is by working through all the possible reasons this could be happening and eliminating each step. This way you will get to the root cause and (ultimately fix) any underlying issues you have with your UPA/ContentDB synchronisation process.

To trouble shoot this issue properly we need to understand what is actually going on and what may be causing the issue – so here goes:

The Theory bit…

When dealing with user profiles it's very easy to get mislead with all the terminology and the path of what actually happens during the site logon process. So this next bit is intended to help clarify the process and hopefully lead us closer to a permanent fix.

When a user authenticates against a site it uses the information in the content database for that Site Collection. This information is kept in the userInfo table and is synchronised with the central User Profile Store by two Sync Jobs:

  • User Profile to SharePoint Full Synchronisation (hourly by default)
  • User Profile to SharePoint Quick Synchronisation (every 5 minutes by default)

The key to these jobs are in the names – which is also why they are routinely misunderstood. Most people think these are the normal full and incremental Active Directory jobs for the user profile application and with the dubious titles it is easy to understand why!

In reality these jobs take information FROM the User Profile Store to the SHAREPOINT content databases throughout the day and they are responsible for refreshing the information in those content databases with the information stored in the User Profile Store.

The incremental job is designed to run every five minutes and only synchronises users that have been set to active since the last synchronisation, whereas the full synchronisation job synchronises all the users' details in the content DB. The idea behind these jobs is to ensure that when a user logs on for the first time that they have to wait for the least amount of time possible before there details are updated (if the incremental job doesn't get you within five minutes the hourly quick job will J )

So when a site collection is setup for the first time in its shiny new DB the userInfo table lists who has, and hasn't got access to the site but until that person hits the site for the first time, the isActive flag for the user is set to zero.

The isActive flag is used by these two jobs to define whether or not the information for a user should be synchronised. So when a user hits the site for the first time, it sets this flag to 1 and the next quick or incremental job will pick this up and synchronise the information accordingly.

This means that when a user logs on for the first time the isActive flag is set to 1, but the information about the user will not be present – hence the display name is not set in this content database – and therefore the user account display name will be set to their user account name which is Domain\UserName.

Once the Full or Incremental jobs pick up the change (i.e. it sees that the user now has a 1 value for isActive) they sync the user's data from the User Profile Store (including the ever important display name) and et viola! On refresh the users display name is changed from Domain\UserName to Display Name (as well as making all the other profile information available like phone number etc.)

So from reviewing this process above and confirming the symptoms we can start to rectify any errors.

Defining the Symptoms – (Potential causes for User Showing as Domain Username)

The way to do this is to ask two simple questions which can go a long way to tracing down the exact source of the error:

  1. If the user logs on to a different site collection (in a different ContentDB) does this still happen?

    This will help you define if the error is localised to the current site collection DB or is spanned across multiple Site Collection DBs. This will help us ascertain whether or not the full and incremental synchronisation jobs are working/running and if the issue is localised to one DB or is farm wide

  2. Is the user set as active in the current site?

    This will tell us if the current site collection is expecting to have the information for the user. If the user has never logged onto the site or has been set to inactive (i.e. they haven't logged on for 30 days – which by default sets isActive back to zero) then they want have their Display Name set until the next Full or incremental job is ran, and then further to this if the jobs have been ran but the user has not been synced we can start to look elsewhere.

The following scripts lists the details of the userInfo Table sorted with the isActive Flag and login and title listed first to help you quickly determine if the user is active or not.

USE [NAME_OF_YOUR_CONTENT_DB_GOES_HERE]

GO

SELECT TOP 10 [tp_SiteID]

,[tp_ID]

,[tp_IsActive]

,[tp_Login]

,[tp_Title]

,[tp_Email]

,[tp_DomainGroup]

,[tp_SystemID]

,[tp_Deleted]

,[tp_SiteAdmin]

,[tp_Notes]

,[tp_Token]

,[tp_ExternalToken]

,[tp_ExternalTokenLastUpdated]

,[tp_Locale]

,[tp_CalendarType]

,[tp_AdjustHijriDays]

,[tp_TimeZone]

,[tp_Time24]

,[tp_AltCalendarType]

,[tp_CalendarViewOptions]

,[tp_WorkDays]

,[tp_WorkDayStartHour]

,[tp_WorkDayEndHour]

,[tp_Mobile]

,[tp_Flags]

FROM [NAME_OF_YOUR_CONTENT_DB_GOES_HERE].[dbo].[UserInfo]

The result should look like this:

How to resolve the issue

The information you have gained from applying the above logic should be pointing you in the right direction by now so here is a list of fix's that can be applied to help rectify the issue

Confirm the users AD account is legitimate and not locked

First and foremost make sure the user is active in AD. It may seem a little obvious but checking it may save you a lot of time – needless to say a user being disabled in AD will not be able to log on to the site.

Confirm the user is an active user of the site

As mentioned above, look at the userInfo table for the site collection DB for the site in questions and see if the user's isActive flag is set. From here you can also see all the other profile information that is available and this will be a good indication of whether or not the account is being synchronised.

Remove and Re-add the user in the site collection

Sometime the user's details may become stale. If you check the contentdb and they are set to active and the jobs are running fine and this issue is related to just one user then deleting and re-adding the user in quick succession will refresh the user data as it does another full import from ad for that user. Once the Full or Incremental jobs pick up the users change status they will synchronise the information again. Don't forget to make a note of the user's security group membership beforehand and add them back in once the operation is complete.

Checking the last time ContentDBs were synchronised

You can check the last time the content DBs were synchronised by using the following STSADM commands. The –listolddatabases command lists all databases that have not been synchronised longer then the day value that you provide. So in this example it lists all DBs that have not been synchronised in the last day:

stsadm -o sync -listolddatabases 0

If you subsequently use the –deleteolddatabases command this will delete the records in the userInfo table in the ContentDBs older than the day value given which means that on the next Full or Incremental sync the table will be totally repopulated. In this case any records not synchronised within the last day will be deleted and repopulated – THE DATABASES WILL NOT BE DELETED! Only the corresponding records in the table:

stsadm -o sync -deleteolddatabases 0

The language used in this command can come across as quite destructive but in all fairness it's essentially triggering a re-sync.

Sync the individual user from AD

You may come across occasions where individual accounts have not been synchronised and removing them and re-adding them from the site collection may not be acceptable.

n.b. This could be for a number of reasons but is most likely to involve the membership of lots of permission groups- so re-adding them to each might be a more labour intensive task than you are willing to undertake

In this scenario you can use the Set-SPUser –syncfromad command which essentially synchronises the user's information table record with the contents of Active Directory. The script below does this for a specific user in one site collection:

add-pssnapin microsoft.sharepoint.powershell

Set-SPUser -identity http://Siteyouwantsync/my -SyncFromAD

This may be the less destructive option for your scenario but please be warned that when the next full or incremental profile sync with AD should trigger an overwrite of this information. This shouldn't be a problem as you've synchronised the user with AD using this command anyway J

Sync All Users from AD

Like the above scenario you may have to re-sync all users in one particular site collection rather than just one user. In this scenario removing each user from the site collection would not be practical and you may have good reasons for not running the Full or Incremental sync jobs. This script iterates through the site collection in question and synchronises each user in turn with AD.

add-pssnapin microsoft.sharepoint.powershell

Get-SPUser -Web http://SiteToSync/my

Get-SPUser -Web http://SiteToSync/my | ForEach-Object {Set-SPUser -identity $_.name -web http://SiteToSync/my -SyncFromAD}

Once again these commands will be overwritten by the profile store information when the next full AD synchronisation takes place.

If in doubt - check FIM!

If by this stage you are still struggling with this issue then you may be having trouble with UPA/FIM and you may need to investigate your full user profile synchronisation and setup. In this scenario I'd refer you to rather brilliant set of blogs by Spencer Harbar at:

http://harbar.net/

Paying particular attention to:

http://www.harbar.net/articles/sp2010ups.aspx

The main point from here will be to check the FIM interface and do a MetaVerse search for your problem user – this will help determine the state of the user and indeed the last time the user's attributes were synchronised with AD.

The FIM client can be found here:

Systemdrive:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

 

One Final Word of Caution…

In this post I've covered two highly contentious and volatile areas, namely:

  • Connecting to SharePoint contentDBs
  • Connecting to the FIM interface

Whilst connecting to these clients and viewing information will not harm your installation you must be aware that ANY changes to ANY SharePoint information contained within SharePoint databases is unsupported and any changes made in the FIM interface are also unsupported – so please, ensure you only use these methods to view information to aid troubleshooting and not as an actual troubleshoot tool! Sermon over… J

Hope someone finds this useful – feel free to send feedback via the comments form on the right hand side.

Permanent Link to Post | Email Post Link | Number of Comments 1 Comment(s)
May 07
.WebTemplateID issues –.WebTemplateID doesn’t report what you’d think
by  Heath GrovesNo presence information  on 07/05/2011 13:48

Whilst in the midst of creating the new move site PowerShell script (http://movesites.codeplex.com) I needed to find out the template id of a site that has been created.  For instance:

Site A was made last year and we need to move it – to do this we need to:
·         Export all the content from site A (to a folder somewhere as a .cmp file )
·         Find out the original site template used to create site A
·         Create a new site based on the original template
·         Import all the site content from the exported (.cmp) file
 

So as you can imagine all the above looked pretty routine for a site move – until I started to investigate the WebTemplateID property.

It would appear that this property returns the web template ID of the very FIRST template that was used to create the site, so if a site has been built on a template from previous and not from scratch then it will report the initial template id and not the current template id.

So why all the fuss?

Well, basically in the early days of SharePoint creation even Microsoft used this method to create their templates.  For instance they created a blank site (STS#1) which would have the initial template ID of 1 and then (rightly so to save effort) they made the team site (STS#0) based on the blank template, but yep you’ve guessed it – the underlying WebTemplateID remained as 1… This is also the case for document workspace (STS#2) which was also based on the blank template and thus has the same initial template ID of 1.

If we list all the templates from the site collections we can see the template ID issue.  To display all the templates use this code (lovingly pilfered from the excellent http://get-spscripts.com):

function Get-SPWebTemplateWithId

{

    $templates = Get-SPWebTemplate | Sort-Object "Name"

    $templates | ForEach-Object {

        $templateValues = @{

            "Title" = $_.Title

            "Name" = $_.Name

            "ID" = $_.ID

            "Custom" = $_.Custom

            "LocaleId" = $_.LocaleId

        }

        New-Object PSObject -Property $templateValues | Select @("Name","Title","LocaleId","Custom","ID")

    }

}

Get-SPWebTemplateWithId | Format-Table

This gives us the output of:

PSTemplate1.png

These are all the default templates and the IDs associated with them – you can clearly see that the template names are individual BUT the web template IDs (in the end column) are grouped in to the original templates that were used to create them.

This screenshot shows the groupings of the initial template IDs:

PSTemplate2Grouped.png

To illustrate the issue even further I created a TEAM Site at http://sp2010blog.com/export and then ran this snippet against it:
 
$web = Get-SPWeb http://sp2010blog.com/export
write-host "Web Template:" $web.WebTemplate " | Web Template ID:" $web.WebTemplateId
$web.Dispose()
 
This returns the values of:
Web Template: STS  | Web Template ID: 1
 
It’s clearly using the underlying site template value for a blank site…
 
….Still – why all the fuss? Can’t you just use the Template Name?
 
Well yes and no – if you are altering the script manually you can change the name manually but if you want to automate the process using a GUI for ease of use then you need to call the template ID programmatically and hence the problem… as calling the name only provides the first portion of the name (up to the #) and requires a separate call to get the id – so in essence it has to be built up, but can’t if the wrong id is reported.
 
The whole point of my the new move sites script is to provide a PowerShell, GUI driven script that can quickly and easily move a site from one location to another without having to edit code all the time – and more importantly do it for free rather than having to purchase very expensive third party products!
So far I haven’t been able to come up with an answer to this conundrum so anyone with any type of info or answer is more than welcome to post using the form on the right.  The Move site scripts uses a drop down and link to this site for the end user to select the relevant template manually, but that is still a no go if you don’t know the source template…
 
One ray of sunshine however is that when you try to import a site into a newly created site made from a different template it bombs out and tells you which template you should be using in the first place which means the original template details are in there… somewhere… so if anyone has any ideas please get posting! J
​

 

Permanent Link to Post | Email Post Link | Number of Comments 1 Comment(s)
May 05
SharePoint 2010 Site Template IDs - Used in the Move Site Script
by  Heath GrovesNo presence information  on 05/05/2011 13:45

Below is the list of the default site templates used in a SharePoint 2010 install. 

Template ID Description Template ID Description
STS#0     Team Site BICenterSite#0     Business Intelligence Center
STS#1     Blank Site SPS#0     SharePoint Portal Server Site
STS#2     Document Workspace SPSPERS#0     SharePoint Portal Server PS
MPS#0     Basic Meeting Workspace SPSMSITE#0     Personalization Site
MPS#1     Blank Meeting Workspace SPSTOC#0     Contents area Template
MPS#2     Decision Meeting Workspace SPSTOPIC#0     Topic area template
MPS#3     Social Meeting Workspace SPSNEWS#0     News Site
MPS#4     Multipage Meeting Workspace CMSPUBLISHING#0     Publishing Site
WIKI#0     Wiki Site BLANKINTERNET#0     Publishing Site
BLOG#0     Blog BLANKINTERNET#1     Press Releases Site
SGS#0     Group Work Site BLANKINTERNET#2     Publishing Site with Workflow
TENANTADMIN#0     Tenant Admin Site SPSNHOME#0     News Site
ACCSRV#0     Access Services Site SPSSITES#0     Site Directory
ACCSRV#1     Assets Web Database SPSCOMMU#0     Community area template
ACCSRV#3     Charitable Contributions Web DB SPSREPORTCENTER#0     Report Center
ACCSRV#4     Contacts Web Database SPSPORTAL#0     Collaboration Portal
ACCSRV#6     Issues Web Database SRCHCEN#0     Enterprise Search Center
ACCSRV#5     Projects Web Database PROFILES#0     Profiles
BDR#0     Document Center BLANKINTERNETCONTAINER#0     Publishing Portal
OFFILE#0     (obsolete) Records Center SPSMSITEHOST#0     My Site Host
OFFILE#1     Records Center ENTERWIKI#0     Enterprise Wiki
OSRV#0     Shared Services Administration Site SRCHCENTERLITE#0     Basic Search Center
PowerPivot#0     PowerPivot Site SRCHCENTERLITE#1     Basic Search Center
PowerPointBroadcast#0     PowerPoint Broadcast Site SRCHCENTERFAST#0     FAST Search Center
PPSMASite#0     PerformancePoint visprus#0     Visio Process Repository

 

This page is used in the move site powershell script so it can dynamically updated for continual use​

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 26
SharePoint 2010 change user display name (Particularly MySite shows domainname\username)
by  Heath GrovesNo presence information  on 26/04/2011 13:55
I’ve come across this error a few times now.  Basically new users have their display name shown with the Netbios name for the network in front of it.  Generally once the user has created a MySite (i.e. they click the My Content link which actually creates the MySite site collection) it generally resolves itself after the next full sync.
 
However in some cases it does not, so I’ve written a little PowerShell script that gathers all the users that have logged onto a SharePoint site and forces a sync with AD – which in turn fixes the error.
 
Here’s the script:
 
add-pssnapin microsoft.sharepoint.powershell
Get-SPUser -Web http://mysite/my
Get-SPUser -Web http://mysite/my | ForEach-Object {Set-SPUser -identity $_.name -web http://mysite/my -SyncFromAD}
 
As always you use it at your own risk, but it’s worked fine for me so far… Happy hunting! J
​

 

***** MAJOR UPDATE *****

Please use this blog post for this issue:

​http://www.sp2010blog.com/Blog/Lists/Posts/Post.aspx?ID=50

It explains the theory behind the error in question 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 20
The required feature is not enabled for this column type managed metadata
by  Heath GrovesNo presence information  on 20/04/2011 10:33

 

This sometimes occurs when you try to use the meta data service on a separate web application or site collection that reside in a separate DB.  Basically you have to enable the feature using STSADM for it register/work with your current managed meta Data service.
 
As a secondary error - you may notice that when using the content type syndication hub, the content type publishing option is not displayed on separate site collections and web applications (specifically anything resident in a different DB to the main Content Type Hub) - activating this feature also rectifies this situation.
 
On your Central Admin/Indexer machine run the following stsadm script
 

For example STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C –url http://intranet/sc -force.

Hope somebody finds this useful! :)​

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 14
SharePoint 2010 Timer Service Stuck Stopping – Usually on a SQL Box
by  Heath GrovesNo presence information  on 14/04/2011 15:31

 

Error
 
Health Analyser states that one or more servers is not responding and on investigation you try to restart the SPTimerV4 service and at that point it sticks in the “Stopping” mode
 
Fix
 
Open Task Manager, Go to Services and find the SPTimerV4 Service - this will be in the stopping state
 
Right click the service select Go To Process, this will switch to the process screen and should highlight OWSTIMER.EXE - if you can't see this make sure the Show Processes from all users is ticked and that display it regardless of the account it is running with, Right Click OWSTIMER.EXE and select End Process.
 
The SharePoint 2010 Timer service should now be showing as Stopped, right click the service and select Start and you should be good to go!
 
Just in case you need to try and stop and start the timer service from the command line you can also try these:
 
SharePoint 2010: net stop
 
SPTimerV4 net start SPTimerV4
 
I’ve found that this issue happens more on SQL boxes and the main reason for correcting it is that deploying .wsps won’t complete unless the timer service on all machines is running correctly.
​

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 12
Enable Lockdown Mode – secure _layouts folder with powershell
by  Heath GrovesNo presence information  on 12/04/2011 13:14

You may find that when you anonymously enable a site that your anonymous access users can still view the  _layouts/viewlsts.aspx and the _layouts/listform.aspx pages on your site.  Although they can’t actually do anything with these pages it is still rather annoying that they can still be surfaced.

To get rid of this lockdown view can be applied.  This view restricts access to the _layouts folder and by default any site that is built using a publishing template will have it turned on by default.  But what happens if you didn’t use a publishing site?  Well in that case you can use powershell to enable it for you:
 
This shows you if the feature is turned in (if it appears in the list it’s on, if it does not appear in the list its off!)
 
get-spfeature -site http://YourSiteCollection
 
To turn it on use the commands below:
 
$Secure = get-spfeature viewformpageslockdown
 
enable-spfeature $secure -url http://YourSiteCollection
                                                                            
May be old hat to some of you but to others it could be a life saver!
 
(Thanks to Darryl Sherborne for jogging my memory!;) )​

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 11
Permissions check on migrated sites using V3 interface
by  Heath GrovesNo presence information  on 11/04/2011 22:35

This one will be short and sweet!

  
When you migrate content over, you may have a need to rain the v3 interface, and if this is the case one of the first things you’ll notice missing is the check permissions option.   However just because ts missing does not mean it can’t be used J

  

Select your list/library/site that you want to check the permission for and navigate to the permissions level.  Now append /_layouts/chkperm.aspx to end of the URL and it will pull up the check permissions page… you have to do this each time unless you add a link to the page, but at least you can still access it J
 
Example:
 
http://www.sp2010blog.com/_layouts/user.aspx?obj=somelistid
 
http://www.sp2010blog.com /_layouts/chkperm.aspx
  
Hope that helps J
Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
1 - 10Next
Alert Me Alert Me
 Photos
Untitled 1
Blog Author/Owner Heath Groves (Click for Profile)
Why not follow me on:
  Follow Heath Groves on Twitter