Just answered a very interesting question in the forums around Colleague Tracker Data. The jist of the question was how do you clear colleague tracker data? After some exploring, I found the data is stored in the UserProfileEventLog table and queried via the [profile_GetUserColleagueEvents] stored proc. There is a profile_ResetAll stored procedure, but if you look at it, it doesn't reset the Event Log data! Bummer for this guy's issue!
Here's the MSDN post
Here are the changes between the content database structure of 2007 and 2010. AGAIN, this is based on beta!
- New Tables:
- Deleted Tables:
- Added Columns
- Delete Columns
- New Stored procedures
- Deleted Stored Procedures
There are the differences between the new object model (Microsoft.SharePoint.dll) and the old. Some classes/interfaces/enums were removed, but nothing that looks to hurt anyone. The really cool part though…no properties or methods were removed between the two versions (doesn't mean that they are not depreciated however)! NOTE:This is based on a beta version of SharePoint 2010.
- Classes/Interfaces/Enums in 2007: 3225
- Classes/Interfaces/Enums in 2010: 6658
- New namespaces in 2010: 46
- I have attached lists of
- All new classes/interfaces
- All removed classes/interfaces
- All Property Changes (adds and deletions) to old classes
- All Methods Changes (adds and deletions) to old classes
I'm CISSP, computer science dude. I can hack your computer, steal your credit card numbers and social engineer you all day long. So when I say SharePoint is not secure, I mean it. Case in point:
- PROOF #1 – Any DBA can dump the contents of your content database by default in 2007 AND 2010. Reference this blog post: http://bit.ly/3pdf45
- PROOF #2 – Web Application policy can be setup to give "Full Control" to anyone the Central Administrator decides to (including him or herself)
- PROOF #3 – Site Collection Admins are "God" when it comes to the data in the Site Collection
- PROOF #4 – Development = Production odds are less than 5% (once you give the developers the database backup, that's it, they own the content)
- PROOF #5 – Ignorance kills your SharePoint – Removing certain blocked file types can cause security holes. Reference this blog post: http://bit.ly/3GpJkp
- PROOF #6 – Blind public deployments of SharePoint to the internet (the _vti_bin problem). Reference this blog post: http://bit.ly/3RjJVD
Are these bad things, technically no if you trust the people you have assigned to each role. But keep in mind, social engineering is a powerful foe!
How does You/I/SharePoint 2007/2010 fix this?
- FIX #1 – 2007/2010 – Implement IRM/DRM – this encrypts your files and locks them down no matter where they will go (covered in my 50149 operations course)
- Search has to be setup to have read access across the IRM domain
- FIX #2 – 2007/2010 – Implement custom actions or event receivers to encrypt the documents when they are "added", "checked in", decrypt on "check out" (covered in my 50064 course)
- Prevents SQL DBA's from PROOF #1
- Problem is, you lose functionality (workflows are "Added", which means the files are encrypted – DOH!, search can't index your content)
- FIX #3 – 2010 only – implement an encryption RBS (watch for this in my future courses)
- Things are awesome, content is encrypted in data store, Search is setup with Read permissions through SharePoint – LIFE IS GOOD, until someone (like me) social engineers your IW staff to give me what I want
- FIX #4 – build some kind of scrub routine on your content database before you give it to your developers
- Hard to do given the structure of the content database, but possible if everything is tagged with content types/meta data (easier to do in SP2010)
- FIX #5 – Don't remove things from blocked file types unless you really know what you are doing!
- FIX #6 – Don't blindly deploy your internet website using SharePoint, reduce your hacker footprint as much as possible!
In reality, there is no security in this world. Sorry…am I fair to pick on SharePoint, no, no matter what platform you choose, same issues will exist!
I have changed the order of the CBT publish to push the SharePoint Governance course. The first module is currently available:
Yep, you heard right. To drive excitement for SharePoint 2010, we are turning all our courses into online versions! I am recording all the courses and turning them into CBT and SCORM! The 50064 course (PPTs and Labs, even the optional ones) has been recorded and I will be publishing the modules one by one over the next few days!
Follow me on twitter to get updates when I publish a module: http://twitter.com/givenscj
Here's the schedule:
As they become available, you can check them out here:
Go SharePoint 2010!
Use this script to find all the closed web parts in your content database:
SELECT w.fullurl + '/' + ad.dirname + '/' + ad.leafname
FROM WebParts wp, alldocs ad, sites s, webs w
where tp_isincluded = 0
and wp.tp_pageurlid = ad.id
and ad.siteid = s.id
and webid = w.id
When exporting a list to .stp, the settings for the list will include the Fields that were added by a content type, and what seems to be the content type definition, HOWEVER, it does not move the content type definitions. The Content Type will only exist for that instance of the List and no others when moving the .stp between sites!
If I was to build a free SharePoint CodeGen tool, what would you want in it? I'll give you some examples:
- Point at any datasource and generate:
- Content Type Feature
- List Template Feature
- List Instance Feature
- Web Parts to "Add/Delete/Modify"
- BDC Application definition creation
What else would the SharePoint community like to have?
I have been working on a lot of codegeneration techniques with SharePoint and approched the BDC today. It seems that it doesn't like things like Guids that much when working with Search Stored Procedures. It will create a default Guid instance and pass that value EVERY TIME! And it will not allow "Wildcard" on Guid Types.
In order to get around this little fact, you have to build a dynamic sql stored procedure (that passes through the query in the proper way to avoid sql injection) that takes all string parameters! Even then there are some types that cannot be compared with the "like" sql operator.
I have everything working like a charm now (keeping to simple types), but man…that was a day's worth of work!