Using SPServices to Query Subsites

SPServices is really a fantastic JQuery library that is specifically designed to embrace SharePoint. My initial brush with it was positive, but then quickly put me into a difficult place to find the answer to (what I thought was) a simple question:

Can SPServices query subsite lists? 

Quick searches insisted the answer was "Yes!", but code suggestions did not prove successful. I found with some trial and error that I could query localized lists (Lists in the current site level) without any issue, but when adjusting the url for subsite lists, I would receive the xml response "Site does not exist".

To explain my scenario, I was attempting to use SPServices to reference a specific list and return a specific field from each submitted item. I narrowed my troubles to a single attribute called "webURL". Many forums (including the documentation I believe) shows the property as "webUrl", which does work and return localized list data. But only "webURL" (notice the case difference) returns data from subsite lists. After making this small, but significant discovery, my code took off!

Hope this helps someone!

<script type="text/javascript" src="jquery-1.7.2.js"></script>

<script type="text/javascript" src="jquery.SPServices-0.7.2.js"></script>

//THIS WOUlD NEED TO BE WRAPPED IN EITHER A FUNCTION OR HANDLER  

$().SPServices({

                operation: "GetListItems",

                async: false,

                listName: "[List Name]",

                webURL: "http://[site]/[subsite]",

                CAMLViewFields: "<ViewFields><FieldRef Name='Title' /></ViewFields>",

                completefunc: function(xData, Status) {

            //THIS IS A HANDY WAY TO CHECK THE RESPONSE AND CLARIFY FIELDS

                //alert(xData.responseText);

                      

                      $(xData.responseXML).find("z\\:row").each(function() {

                      

        var liHtml = "<li>" + $(this).attr("ows_field15") + "</li>";

        $("#taskItems").append(liHtml);

        

         });

        }

                                                

});

   

}

 

<ul id="taskItems" />

User Profile Synchronization Service - Another Way to Fix "Hung on Starting" Issue

COMMON GROUND

I know that many of us SharePoint administrations and developers have encountered the dreaded "starting" issue for the User Profile Synchronization (UPSA) service at least once in our careers. The truth is, the process became so terribly complicated with the adoption of Forefront Identity Manager(FIM) in SP2010. I've read gads of commentary empathizing the pains of setting this up, using it, and maintaining it, lending credence to the idea that it's almost not worth the struggle. However, if you CAN get it to work and stay so, it does offer some beneficial features to the user community for organizational information.  It does offer a solution for pulling attribute data straight from Active Directory and mapping it to SharePoint fields, which can be leveraged in a variety ways. I'm of the belief it was created with "good intentions" but VERY, VERY poorly constructed (My best guess is that Forefront and Microsoft were so completely thrilled when they finally got UPSA to work that they gave up attempting to make it friendly in any reguard). In my long and frustrating attempts to fix the latest problem (The service indefinately stuck on "starting"), I created the below map (Which also helps to illustrate how utterly crazy UPSA is). 

THE ISSUE

So as I promised, I did find an answer, after rougly a week of digging into how fix the "starting" trouble. I read through every forum and bit documentation I could find, trying to both understand as much as I could about this dreaded concept, and find a reason why it wouldn't work (I reviewed logs in Verbose mode from Windows, and both the SharePoint diagnostic and IIS logs via ULSViewer). According to the logs, I could see SharePoint attempting to work with FIM and would get so far as "ILM: Created Certificate". Following this, nothing would come from UPSA (Other SharePoint activities would continue on). No failures were reported. No errors were captured. It remained this way (I left it on "starting" for 24 hours) until I purposely terminated the service instance and killed the "UserProfileSyncSetupJob" in the timer queue. Each attempt would successfully create one Forefront certifcate (MMC snap in for "certificates", Computer Account) in the Trusted Root Authority folder, and everything I could find on the subject indicated there should be two within this folder when successfully completed, but noted they would be almost indistinguishable from each other, as both are named the same. I'd faithfully purged the one within the Trusted Root Authority folder each attempt. 

THE ANSWER

I'll caution you; there are some very interesting forum posts out there, offering some wild advice on how to resolve this issue, most of which suggest deleting and recreating UPSA. Please note - THIS IS LIKELY NOT NECESSARY. For my case, I finally discovered (With the help of an inspired person's comments off a related post) that certificates are created in both the Trusted Root Authority folder AND the Personal folder. The Forefront certs have to be deleted from both for the service to start, as FIM creates one cert in Trust Root Authorities AND another in Personal. 

THE END

I truly hope this helped someone, as this killed almost of a week of my time. If you should observe a collection of Forefront certs building up in the two folders, (IF UPSA is stopped) it is safe to purge these (The certs will be recreated, when successfuly restarted or "reprovisioned" as Microsoft likes to phrase it). Good hunting to you!