To work around this I wrote a utility in C# to provide some basic capabilities like upload, download, deleting a blob and listing the contents of a blob container.

Go here for the CodePlex project: https://petesazureblobtool.codeplex.com/

The public method GetS2SClientContextWithWindowsIdentity calls the private method GetClaimsWithWindowsIdentity:

private static JsonWebTokenClaim[] GetClaimsWithWindowsIdentity(WindowsIdentity identity)
       {
           JsonWebTokenClaim[] claims = new JsonWebTokenClaim[]
           {
               new JsonWebTokenClaim(TokenHelper.NameIdentifierClaimType, identity.User.Value.ToLower()),
               new JsonWebTokenClaim("nii", "urn:office:idp:activedirectory")
           };
           return claims;
       }

If you look at the value of identity.User.Value.ToLower(), it turns out that that is a Windows SID. To make this work without a domain, you will have to get the SID of a user from your SharePoint server. You do that via PsGetSID from SysInternals or write a little PowerShell do it (see https://powershellers.blogspot.com/2009/06/how-to-get-computer-sid-using.html).

I extended TokenHelper via extension methods. I don’t like to change generated code in case it gets changed later (although I did have to mark the TokenHelper class partial).

Here is the code that I created so that you can pass a SID:

public partial class TokenHelper
   {

       public static ClientContext GetS2SClientContextWithWindowsSID(
         Uri targetApplicationUri,
         string sid)
       {
           string realm = string.IsNullOrEmpty(Realm) ? GetRealmFromTargetUrl(targetApplicationUri) : Realm;

           JsonWebTokenClaim[] claims = GetClaimsWithWindowsSID(sid);

           string accessToken = GetS2SAccessTokenWithClaims(targetApplicationUri.Authority, realm, claims);

           return GetClientContextWithAccessToken(targetApplicationUri.ToString(), accessToken);
       }
       public static string GetS2SAccessTokenWithWindowsSID(
          Uri targetApplicationUri,
          string sid)
       {
           string realm = string.IsNullOrEmpty(Realm) ? GetRealmFromTargetUrl(targetApplicationUri) : Realm;

           JsonWebTokenClaim[] claims = GetClaimsWithWindowsSID(sid);

           return GetS2SAccessTokenWithClaims(targetApplicationUri.Authority, realm, claims);
       }

       private static JsonWebTokenClaim[] GetClaimsWithWindowsSID(string sid)
       {
           JsonWebTokenClaim[] claims = new JsonWebTokenClaim[]
           {               
               new JsonWebTokenClaim(TokenHelper.NameIdentifierClaimType, sid),
               new JsonWebTokenClaim("nii", "urn:office:idp:activedirectory")
           };
           return claims;
       }

   }

To call this from your app, do this:

TokenHelper.TrustAllCertificates();
var sharepointUrl = new Uri(Request.QueryString["SPHostUrl"]);           
string sid = ""; //replace this
var clientContext = TokenHelper.GetS2SClientContextWithWindowsSID(sharepointUrl, sid);

A full explanation of the TokenHelper class is beyond the scope of this post but you might find this article helpful: https://msdn.microsoft.com/en-us/library/fp179901.aspx.

Once I did that, it worked!

Basically, if you have more than one site collection in the database, stay under 100GB. If you only have 1 site collection in the database and are using it for collaboration, you can go up to 200GB. You can go up to 1TB if that content is not for active collaboration and is primarily read-only content(e.g. Records Center).

Should you find yourself having to debug a sandbox solution remotely you can do the following to get it working.

• First, make sure that you have the Microsoft SharePoint Foundation Sandboxed Code Service running in Central Administration:

Note: In a multiple server farm deployment, you will want to make sure this service is running on only 1 machine to make things simpler.

• You will need to copy the debug symbols to the SharePoint server before you can debug. By default the PDB file will be located in your Visual Studio project’s obj directory:
  
• Copy the PDB file to C:\ProgramData\Microsoft\SharePoint\UCCache. Note that c:\ProgramData is a hidden folder. Within this UCCache folder you should see one or more autogenerated folders that look something like this:
   

From here you will need to do a search to find your code’s DLL assembly file. Also, this folder may not appear until you first hit the SharePoint page that is using the code.

• Next, you will need to launch the Remote Debugger x64 (MSVSMON.exe) on the remote SharePoint server. By default this is located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64 (note: you need the x64 version). Copy this whole directory to the SharePoint server and launch msvsmon.exe. If it works, you should see something like this:

• Launch Visual Studio 2010 on your developer machine. Both the developer and server machines should be in the same Active Directory domain for managed code debugging. Open your Visual Studio SharePoint project that you wish to debug.
• Launch your web browser and hit the page with your SharePoint code on it
• Go into the Debug menu and select Attach to Process. Type the remote server name in the Qualifier box and hit Enter (note: username/domain name will appear in this box automatically). Select the SPUCWorkerProcess.exe. If your User Code service is running under a different account, you may get a warning when you try to attach.
  
• Go into Modules under the Debug, Windows menu (Ctrl +D M). If all is well, you should see something like this:
  
• Set a breakpoint in your code and go back to your web page and hit refresh. At this point, Visual Studio should hit your breakpoint.
  
• Final note, when I was trying this I saw that new autogenerated folders with my code appeared in c:\programdata. If this occurs, re-copy the PDB file. You may also be able to add the PDB file to your Symbol path. However, I did not get this working on my machine (I got Symbol file does not match the module)

Change the Target as follows:

From C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit  " & ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ' "

to C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1"

(Change paths as required)

After it starts up, hit the Run Script (F5) button to run the script.

At this point, you can work in the PowerShell_ISE

These articles were especially helpful in getting this working:

https://blogs.msdn.com/opal/archive/2010/03/24/faq-sharepoint-2010-remote-blob-storage-rbs.aspx

https://technet.microsoft.com/en-us/library/ee663474(office.14).aspx

https://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=174

SQL Server saves all of the blobs in an NTFS directory of your choosing:

For fault tolerance you would want this to be a shared drive on a SAN that is shared between the nodes in the Windows cluster.

Here are some additional points to keep in mind:

1) These files are not encrypted by default. If you take a file and change the file extension to the appropriate type (PDF, DOCX, etc.), an administrator will be able to view it.

2) If you delete a BLOB in the file system, SharePoint will return a 404 error when you attempt to open the file, but the icon will still show up in the document library.

3) If an administrator attempts to modify the file outside of SharePoint, Office will report that the file is corrupt but it will still open as a new file.

An error occurred during the processing of /_catalogs/masterpage/Intranet.master. Code blocks are not allowed in this file. 

I tracked it down to this code block:

<%# Eval("text") %></div>

It's easy to forget but you have to manually migrate settings from the old 2007 web.config to the new one. The one that allows script blocks is:

<PageParserPaths>
<PageParserPath VirtualPath="/_catalogs/masterpage/Intranet.master" CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>

Other possible workarounds are to 1) remove the offending Eval (note: you'll lose functionality) or 2) change the master page to default.master by going to _layouts/settings.aspx and click the Master page link.

 startsharepoint.bat:

net start IISADMiN
net start w3svc
net start DCLauncher14
net start DCLoadBalancer14
net start MSSQL$SHAREPOINT
net start SQLWriter
net start WebAnalyticsService
net start SPTimerV4
net start SPTraceV4
net start W3SVC
net start SPWriterV4
net start SPAdminV4
net start OSearch14
net start SPSearch4
net start SPUserCodeV4

stopsharepoint.bat:

net stop IISADMiN
net stop w3svc
net stop DCLauncher14
net stop DCLoadBalancer14
net stop MSSQL$SHAREPOINT
net stop SQLWriter
net stop WebAnalyticsService
net stop SPTimerV4
net stop SPTraceV4
net stop SPUserCodeV4
net stop W3SVC
net stop SPWriterV4
net stop SPAdminV4
net stop OSearch14
net stop SPSearch4

Note that this list is for SharePoint Server. If you are running SharePoint Foundation, you won't need all of the ones listed above. Also, if you are running SQL Server rather than SQL Express, then change MSQL$SharePoint to MSSQLServer.

Update: Accidentally had the User Profile Service for Windows in there. Removed it. Thanks, Pete

Currently, I have the tech beta of SP 2010 in the native boot VHD and have set all the SharePoint, web, and SQL services to manual start. As you may know from https://blogs.msdn.com/sharepoint, SharePoint 2010 is going to require x64 and likely more RAM to run well than SP 2007 so native boot VHD is definitely better than trying to run it in VM on a laptop. While we are supporting running SharePoint on Windows 7 x64 or Vista x64, I decided that it was probably a better idea not to install it on my production Win 7 environment. You can even enable Hyper-V in the native boot VHD! I’m doing this to run MOSS 2007 x86.

This resource helped me during the setup. Essentially, you have to add a virtual disk in Windows 7 and then start Windows Server 2008 R2 setup and use the virtual disk. https://technet.microsoft.com/en-us/library/dd799299(WS.10).aspx