SharePoint 2010 without a domain

SharePoint 2010 Deployment without a Domain is only supported using the Standalone Install Option, this is where the SharePoint and SQL exist on the same server, the Standalone options should only be implemented for Development and Evaluation of SharePoint 2010.

However if you required the SQL Server to be separated from SharePoint 2010 you could consider the following workaround, this is not my recommendation and I would recommend the Alternative Solution described below:

Workaround:

To Allow SharePoint 2010 to be deployed using a Separate SQL Server and No Windows AD Domain the following steps can be followed:

1. Changing Either Setting:�
   1. The registry entry HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0WSSServerRole == SINGLESERVE 
   2. Or Modifying the installation config.xml found on the SharePoint Media, including the follow entry  <SettingId=”AllowWindowsClientInstall” Value=”True”/
2. Then Using Either Commands:�
   1. PowwerShell command “New-SPConfigurationDatabase” http://technet.microsoft.com/en-us/library/cc288606.aspx 
   2. or PSConfig.exe configdb (http://technet.microsoft.com/en-us/library/cc288944.aspx)

NOTE: you will need to use the dbusername and dbpassword switches for provided the SQL Login Details.

Known Limitations:

1. Search Server 2010 Express does not deploy in this Scenario
2. You cannot have multiple SharePoint Servers
3. User Profile Import does not deploy as a domain User Account is required for FIM

Alternative

The Main reason I have seen organizations consider deploying SharePoint without a Windows AD domain is where SharePoint is being deployed into the DMZ, historically Windows AD does not normally exists in the DMZ, and therefore to Deploy Windows AD would require additional infrastructure and Windows AD User CAL’s

There is no way around the additional infrastructure (hardware) costs, however if you are deploying SharePoint you must already have an investment and adding additional hardware would be a small overhead, however the licensing costs would not be, an alternative would be to store all user account (who authenticate against SharePoint) in SQL Server and use the ASP.NetProvider FBA for Authentication and Authorisation, this way the you would only need to license Windows AD per seat for the Servers Joined (SQL, SPPS) and store only the service accounts required by SharePoint in the Windows AD Domain, limiting the CAL cost dramtically.

It is recommended that you provision a Windows Active Directory Domain for SharePoint 2010, so that the SharePoint Service Accounts and Server Objects can be stored. For windows licensing reasons you may wish to use the ASP.NetProvider for authentication, and store the user credentials in a SQL DB. This configuration is fully supported and allows the SharePoint to be scaled up, and Windows AD user CALs will not be required.

NOTE: Licensing should be checked by your LAR or Microsoft, the details in this post is provided as examples.