Assumptions:  Is this a proposal? 

1. SharePoint 2010 running on Windows 2008 R2 (64 bit of course)
2. You have at least configured a couple of Web Applications in SP2010 to make the rest of this work

The main thing that happens here is you try to install BizTalk 2009 and you have the option for the SharePoint Service Adapter all greyed out.  This doesn’t work so go ahead and do the following:

1. Download WSS 3.0 with SP2.  NOTE:  This is required for Windows 2008 R2 as it will not let anything else be installed
2. Before you get to the area to actually “Configure SharePoint…”, hit “Cancel”
3. Run the install for BizTalk and you can not install the adapter
4. Configure the adapter as you would because it will recognize SharePoint is installed
5. After it is configured, change the web.config for the BizTalk adapter to use the 14.0.0.0 services (See this post here)

Hopefully that at least gets you a bit further.  Hopefully BizTalk 2009 R2 will have a lot of this resolved.

You ever looked at what happens after you go to a list and sign up to receive something that you didn’t change?  If you see the CAML query that SharePoint generates, you might be asking yourself “what is this?”.  The FieldRef points to a “Editor/New” column.  What the heck?  That doesn’t exist anywhere.  Then again, Editor does, but what is this “New” thing?  Look at some other types and you will see the “Editor/Old” popping up.  Getting where I am headed?  You know the SPAlert.Filter property has a get; and a set;, right?  Hmmmmm…let your imagination do the rest.  Create the SPAlert manually, or script it…you will like it.

$alert = $web.AllUsers["domain\kirkhofer"].Alerts.Add();
$alert.Filter = "<Query><Neq><FieldRef Name="_Status/Old"/><FieldRef Name="_Status/New"/></Neq></Query>";
$alert.List = $list;
$alert.AlertType = [Microsoft.SharePoint.SPAlertType]::List;
$alert.Title = "Status Change";
$alert.EventType = [Microsoft.SharePoint.SPEventType]::Modify;
$alert.AlertFrequency = [Microsoft.SharePoint.SPAlertFrequency]::Immediate;
$alert.Update($false);

$siteurl = "http://blah"
$site = new-object Microsoft.SharePoint.SPSite $siteurl
$web = $site.OpenWeb()

stsadm -o deactivatefeature -url $siteurl -name OffWFCommon
stsadm -o deactivatefeature -url $siteurl -name TranslationWorkflow

$site.features|%{$_.Definition}|?{$_.ReceiverAssembly -like "*Office*"}|select DisplayName
$site.features|%{$_.Definition}|?{$_.ReceiverAssembly -like "*Office*"}|%{stsadm -o deactivatefeature -url $site.url -name $_.DisplayName}

stsadm -o deactivatefeature -url $siteurl -name TransMgmtLib

$web.features|%{$_.Definition}|select displayname,status

1. Create a for and add a Date Picker field to the view
2. Double-click the field and add a new Rule
3. Set the Condition as such: 
   1. string-length(.) = 6 and
   2. contains(“/”, .) = false and
   3. contains(“-”,.) = false
4. Add an Action to Set a Fields Value
   1. Current Field or “.”
   2. Value: concat(substring(today(), 1, 2), substring(., 5, 2), “-”, substring(., 1, 2), “-”, substring(., 3, 2))
5. Test out the for.  Enter a date like “050109″ and it will put it in as 2009-05-01.

That is it.  Simple and easy to use

Save your InfoPath form File -> Save As Source Files…  From there go in and edit the view1.xsl or whatever you named your view.  Look for the <option> tags and in there you will find the <xsl:value-of/> tag with the field you chose in the display name.  Now, just add the additional stuff you want, and whala:

<xsl:value-of select="@field1"/>-<xsl:value-of select="@field2"/>

Save the file and open the manifest.xsf in Design mode and take a look

Let’s assume the following scenario: 

Database moving from: DB1

Database moving to: DB2

Site GUID:  A63289FB-5404-4B17-BB49-4378EEF2CDB7

Steps in the SQL Profiler world…not exact but you get the point

–Lock the site in DB1

–Same as STSADM -o setsitelock -url site -lock noaccess

exec proc_SetSiteFlags ‘A63289FB-5404-4B17-BB49-4378EEF2CDB7′,131072,131072

–Run a bunch of INSERT INTO DB1.[dbo].[Table] (Col1,Col2,…) SELECT Col1, Col2,… FROM DB2.dbo.Table

Sites

ComMd

Deps

AllDocs

AllDocStreams

AllDocVersions

ContentTypes

EventReceivers

Features

ImmedSubscriptions

AllLinks

NavNodes

ScheduledWorkItems

SchedSubscriptions

Webs

Groups

GroupMembership

Roles

RoleAssignment

Workflow

WorkflowAssociation

Perms

RecycleBin

SiteVersions

NameValuePair

NameValuePair_Albanian_CI_AS

.

.

.

NameValuePair_Vietnamese_CI_AS

BuildDependencies

AllUserData

UserInfo

WebParts

Categories

AllLists

ContentTypeUsage

WebCat

WebMembers

WebPartLists

Personalization

exec proc_SetSiteFlags ‘A63289FB-5404-4B17-BB49-4378EEF2CDB7′,0,131072

exec proc_DeleteSite ‘A63289FB-5404-4B17-BB49-4378EEF2CDB7′

–Config DB

exec dbo.proc_dropSiteMap @Id=’A63289FB-5404-4B17-BB49-4378EEF2CDB7′

exec sp_executesql N’UPDATE [DB2].[dbo].[Sites] SET BitFlags = @Flag WHERE Id = @SiteId’,N’@SiteId uniqueidentifier,@Flag int’,@SiteId=’A63289FB-5404-4B17-BB49-4378EEF2CDB7′,@Flag=0

–Config DB

declare @p8 int

set @p8=1

exec dbo.proc_putSiteMap @ApplicationId=’A32D6D58-99F5-437F-BE32-3233D242BF91′,@DatabaseId=’DF61C0F9-1F4C-49B2-B1A9-99276320359E’,@SiteId=’A63289FB-5404-4B17-BB49-4378EEF2CDB7′,@Path=N’/sites/tester’,@Pairing=0,@RedirectUrl=NULL,@HostHeaderIsSiteName=0,@CurrentDatabaseSiteCount=@p8 output

select @p8

That is it…I know, not the prettiest thing, but SQL people get it and now hopefully so does everyone 

If you have a Site Collection marked as “readonly” and it happens to be the last Site in the SharePoint table Sites, it will basically disable you from editing EVERY user/group in SharePoint that is within the same Content Database.

So how could someone figure this out? A lot of SQL skills help, and I gots em…

To replicate this problem, do the following:

1. Create a new Web Application and a new Content Database in Central Administration (WEB APP=http://test, Content Database=SP_TEST_CONTENT)
2. Create as many site collections as you want:
   1. “/” root Blank
   2. “/sites/T1″ Blank
   3. “/sites/T2″ Blank
3. Open up SQL Management Studio (SSMS) and run a query like this: SELECT  s.id,s.BitFlags,w.FullUrl FROM SP_TEST_CONTENT..Sites s JOIN SP_TEST_CONTENT..Webs w ON s.Id = w.SiteId
4. Take note to the one that is last, if it is “”, it is root.  Now, go to a command line and do the following: “stsadm -o setsitelock -url http://test/<Full URL from above> -lock readonly”
5. Go to any of the site collections that ARE NOT marked as read-only and try to add a user/group…ACCESS DENIED

So what is the deal?  SQL skills take over…  I opened up SQL Profiler and watched what was going on.  The one line that got me was calling “proc_SecAddUserToSiteGroup”.  Upon looking at this SPROC with “sp_helptext proc_SecAddUserToSiteGroup” I saw another call to “fn_CanUserEditMembershipOfGroup”.  After doing the same thing on this call, found a line like the following:

SELECT @SiteFlags = BitFlags FROM Sites

All in all valid SQL statement, however, one big gaping hole…uh….WHERE CLAUSE!!!!!!!!

After this call, it looks for IF @SiteFlags & 131072 = 131072 RETURN 0.  DOH…that pretty much mean ACCESS DENIED!!!!

Microsoft, please fix this bug…

1. Turn on AJAX for thw web.config (I follow Jan T’s solution for integrating AJAX the lazy way)

2. Create a web part page (ASP.Net AJAX project with 3.5) and use the UpdatePanel and the ScriptManager
        – There are several ways to do this without adding the ScriptManager to the .master page. 

3.  Make sure to add the EnsurePanelFix JavaScript thing…you can find that about anywhere on the net

4.  The most important thing, you have to make sure the master page is set up properly!!!!!!!!
         – For example, the default.master in SharePoint, works fine, however, blueband.master (and all the other ones in publishing “MasterPages”) have some flaws
                     – <Title>:  This is on separate lines, move this all together:

<Title ID=onetidTitle><asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/></Title>

                    – SPWebPartManager: This needs to be Inside the <form> tag

<form runat="server" onsubmit="return _spFormOnSubmitWrapper();">
<WebPartPages:SPWebPartManager id="m" runat="Server" />

If you use the default.master page that is in the publishing master pages, it works FINE...so the chance that they were close and the issue was in the master page was high.  I sure hope this helps someone else.

Links:
- Walkthrough: Creating a Basic ASP.Net AJAX-enabled Web Part
Good reference, even though this is for the old toolkit. About everything here can be applied to the current stuff

This new script is a complete one that can be scheduled on your WFEs.  If you didn’t know already, all the Application Pools that get created are scheduled to reset themselves at a certain time.  Usually around 2 AM in the morning.  So if you want, take this script and put it in a CMD or BAT file and put an IISRESET right in front of it.  Then, add the code I have provided in a PS1 script and you are off and gunning.  You can remove those app pool recycles that are scheduled.

Save the following in a script named SPWarmUp.ps1

############################################################################
#Assumptions:
#-Running on machine with WSS/MOSS
#-C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN in path
############################################################################
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}

#This passes in the default credentials needed. If you need specific stuff you can use something else to
#elevate basically the permissions. Or run this task as a user that has a Policy above all the Web Applications
#with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential("username","password","machinename")

[xml]$x=stsadm -o enumzoneurls
foreach ($zone in $x.ZoneUrls.Collection) {
    [xml]$sites=stsadm -o enumsites -url $zone.Default;
    foreach ($site in $sites.Sites.Site) {
        write-host $site.Url;
        $html=get-webpage -url $site.Url -cred $cred;
    }
}

When you schedule this to run through a scheduled task, make sure the user running this has the correct credentials on the sites being hit.  Obviously, make sure this is on ALL WFEs.

Can you test this without all the other stuff?  Sure, just copy and paste the code and put it in to PowerShell and give it a whirl.

Download the file here