O365 Snag, Grouped view in public site: Working On It......(for anonymous users)

So,
I'm helping out a small business by creating an online exposure for them via O365. Just showing the products, with a product-code in a category and an image.
There are about 3000 products so showing them all at once sounds like a bad idea.. Let's just group them on the category, users can open a category and see all product with a little product image (thumbnail) and in the future select them to get a quote for them.
Of course, all of this happens in the "public" = "anonymous" part of the 0365 site.

I'm sorry .. but that's not going to work !
Microsoft support (SRX1219692554ID) suggests you better use an alternative view without the grouping functionality. (That's the final "work around" they gave me after some extensive testing).

As it turns out, the anonymous users don't have sufficient permissions to access this information, resulting in a "working on it" status as soon as these anonymous users hit the + sign before a group. This status won't change.. no matter how long you wait for it; in the background O365 is trying to redirect these users to the login page which in not going to work for these type of users.

Authenticated users see the products in a category:

Anonymous users just see "Working on it..."

The "work around" is of course not helping at-all, there are no other views that have this functionality.. I'm not even daring to think to create a Access APP (view) that can host this functionality for anonymous users...

Big snag !! Maybe some JavaScript + XSLT to the rescue.. I'll post a real work-around as soon as I find one !

3rd Party Apps that leave their Sh#!T behind...(or crash your farm in the removal process)

You know the situation, lots of time pressure on the project, the client needs a little [treeview] [search optimizer] [birthday calendar] [pdf / cad / xxx viewer] [etc] (select or choose your own) addition to the SharePoint implementation.
There is no budget, because .. why should we by this ??! Doesn't it come with SharePoint ? We'll think about it when we see it working...

And you know you should use the dev / test environment to run these trials on .. but hey... sometimes there is only 1 environment...

STOP... Don't DO IT !!

Chances are that the 3rd party tool you are installing is NEVER going to leave the farm / web app / site collection, or you going to spend ALLOT of time cleaning up after you try to remove it.
Maybe you don't care what's left behind.. until you see the warnings appear in the health-analyzer.. Maybe you don't look in the health analyzer ? You will... once you install a CU or want to upgrade to SharePoint 2013.. Which won't work.. because there are some missing components ! ALERT ALERT ALERT !!! Of course you did a trial upgrade .. right !?!

The above scenarios I consider "lucky'", in one occasion I saw the whole farm die when I uninstalled a 3rd party product; giving a nice correlation ID message to all visitors until YOU the admin who broke everything (euh.. I clicked uninstall... wtf ?!?! ) will FIX IT ! (For free of course.. )

Things that can get left behind (also after the neat uninstall says "finished":
- Event receivers (in every single site (collection) !
http://speventreceiverman.codeplex.com/

- Web Parts
(web part gallery)
http://etienne-sharepoint.blogspot.com/2011/10/solving-missingwebpart-errors-from.html

- Assemblies
http://etienne-sharepoint.blogspot.com/2011/10/solving-missingassembly-errors-from.html?showComment=1380725089569#c3924490290473490722

- Setup Files
http://etienne-sharepoint.blogspot.com/2011/10/solving-missingsetupfile-errors-from.html

-Features
http://featureadmin.codeplex.com/

Add DB server IP to localhost when using SQL Alias

So, when you implement the "best practice" of using SQL Server ALIAS names (to be flexible at all times of where your SharePoint databases will be hosted), apparently it's also a best practice to add the IP & ALIAS name to (all) your WFE & APP's that are using this name.

This came to my attention when I started receiving ERROR logs in the windows APP log of a WFE:

Log Name: Application

Source: Microsoft-SharePoint Products-SharePoint Foundation

Date: 2013/10/02 07:24:00 AM

Event ID: 6398

Task Category: Timer

Level: Critical

Keywords: 

User: **

Computer: **

Description:

The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPDatabaseServerDiagnosticsPerformanceCounterProvider (ID 5bce4422-820a-465f-aee4-5ce0f31640ce) threw an exception. More information is included below.

SharePointDbServer:The network path was not found.

;

Please ensure that the database server is available

Eh.. duh.. of course the database server is available.. I personally know the DBA ! :P :P 

(Yeah, he's one of my personalities)...

Ok; so .. apparently when you use the SPDiag toolkit from MS, this toolkit starts monitoring stuff and will trigger above ERROR in your eventlog, as being described here:

http://social.technet.microsoft.com/Forums/sharepoint/en-US/4b397f6c-249a-43f0-aa91-ff210e4e132b/timer-event-6398-spdatabaseserverdiagnosticsperformancecounter

Thank you so much Mohammed Al-Basri for pointing this out :) 

I added the HOME ip (in this case it's a single server install) 127.0.0.1 + DB ALIAS name and voila, another problemo solved !