SharePoint Solution Generator is dead (for good) - Part 1

SharePoint Solution Generator, part of Visual Studio 2008 extensions for Windows SharePoint Services has been a fantastic tool in SharePoint 2007 development when I needed to create a list definition and list instance quickly.

All you had to do was to create your content types,site columns, and list using SharePoint UI and apply the content types and site columns to your list, then customise your list and create views then finally point solution generator to your list and create your solution package.

 

Combination of the new features of SharePoint 2010 and Visual studio 2010 means no more messing around with add-ons….

SharePoint 2010 allows you to save your site as a wsp package and Visual studio allows you to import the wsp package and select the required elements to include in your solution package! sounds easy? it is :)

 

…so first you need to create your list as before with all required components and customisations:

1) Create your Site Content Type

2) Create your Site Columns

3) Assign your site columns to your content type

4) Create your list/library and assign your content type to your list

To be able to do this you need to ensure you have selected “allow management of content types” from the list advanced settings

5) Save your site as WSP package

Site Action –> Site Settings –> “Save site as template”

provide a file name and a template name for your template

Download the WSP file and save locally

6) Import the WSP package into Visual Studio 2010

Create a Visual Studio SharePoint project and select “Import SharePoint Solution Package”

Import the WSP file

Specify the project elements required in this case the list template

The easiest way to do this is to highlight all items (Ctrl + A) and  deselect one item. this will uncheck all boxes

Then select the “List instance” and “Content type” and click finish (You do not need to include the columns)

Say No to include all dependent items

Now you have all required components for your solution

There are a number of considerations which I will try to cover in the next posts such as including Lookup and Managed Metadata filed types in your solution.

Automated SharePoint 2010 AD service accounts creation using PowerShell

As I don’t really enjoy repetitive tasks, I decided to put a quick PowerShell script together to create the AD service accounts required for SharePoint 2010.
The required accounts are:

• svc_spFarm (Server farm account or database access account)
• svc_spAdmin (Setup user account Install Account)
• svc_caAppPool (Application Pool Identity for Central Administration web application)
• svc_portalAppPool (Application Pool Identity for Portal web application)
• svc_myAppPool (Application pool Identity for my sites host web application)
• svc_spUPS (User Profile Synchronisation with AD)
• svc_spUPAPool (User Profile Services Application Pool account)
• svc_spSearch (This is the Windows Service account for the SharePoint Server Search Service. This setting affects all Search Service Applications in the farm)
• svc_spCrawl (Content Access account)
• svc_spSearchAP (Enterprise Search Application Pool Identity)
• svc_spSearchAdmAP (Enterprise Search Admin component Application Pool Identity)
• svc_fsSearch (Foundation server search account)
• svc_fsCrawl (Foundation server crawl account)
• svc_spSandbox (Sandbox service service account)
• svc_WebAnalytics (SharePoint Web Analytics service account)
• svc_SecureStore (Secure Store Application Pool service account)
• svc_spSTSAcct (Security Token Service Application)
• svc_spMetadata (Managed Metadata Service Account)

(Other accounts may be required depending on services running on the farm such as InfoPath services, Visio, etc…)
Please note The following additional domain , local and SQL permissions / roles are required:
svc_spAdmin:
Member of the Local Administrators group.
SQL Server login on the computer that runs SQL Server.
Member of the following SQL Server security roles:
    · securityadmin fixed server role
    · dbcreator fixed server role
    · sysAdmin fixed server role (during installation using PowerShell only)
svc_spFarm:
Member of the Local Administrators group during the user profile services configuration only.
svc_spUPS:
AD Delegate rights for Replication Directory Changes permissions
The PowerShell command takes a csv file containing the following headings:

• samAccountName   
• userPrincipalName
• cn
• givenName
• Password
• description

Copy and paste the following into a csv file called acc.csv (ideally this needs to be an XML):
samAccountName,userPrincipalName,cn,Password,description
svc_spAdmin,svc_spAdmin@domainName.FQDN,svc_spAdmin,accountPassword,The Setup user account is used to Setup SharePoint Products Configuration
svc_spFarm, svc_spFarm@domainName.FQDN,svc_spFarm,accountPassword,The server farm account is used to Run the Microsoft SharePoint Foundation and workflow Timer ServiceWizard
svc_caAppPool,svc_caAppPool@domainName.FQDN,svc_caAppPool,accountPassword,Application Pool Identity for Central Administration web application
svc_portalAppPool,svc_portalAppPool@domainName.FQDN,svc_portalAppPool,accountPassword,Application Pool Identity for Portal web application
svc_myAppPool, svc_spAppPool@domainName.FQDN,svc_myAppPool,accountPassword,Application pool Identity for my sites host web application
svc_spUPS,svc_myAppPool@domainName.FQDN,svc_spUPS,accountPassword,User Profile Synchronisation with AD
svc_spUPAPool,svc_spUPAPool@domainName.FQDN,svc_spUPAPool,accountPassword,User Profile Services Application Pool account
svc_spSearch, svc_spSearch@domainName.FQDN,svc_spSearch,accountPassword,This is the Windows Service account for the SharePoint Server Search Service. This setting affects all Search Service Applications in the farm
svc_spCrawl, svc_spCrawl@domainName.FQDN,svc_spCrawl,accountPassword,Content Access account
svc_spSearchAP,svc_spSearchAP@domainName.FQDN,svc_spSearchAP,accountPassword,Enterprise Search Application Pool Identity
svc_spSearchAdmAP,svc_spSearchAdmAP@domainName.FQDN,svc_spSearchAdmAP,accountPassword,Enterprise Search Admin component  Application Pool Identity
svc_fsSearch,svc_fsSearch@domainName.FQDN,svc_fsSearch,accountPassword,Foundation server search account
svc_fsCrawl,svc_fsCrawl@domainName.FQDN,svc_fsCrawl,accountPassword,Foundation server crawl account
svc_spSandbox,svc_spSandbox@domainName.FQDN,svc_spSandbox,accountPassword,Sandbox service application service account
svc_WebAnalytics,svc_WebAnalytics@domainName.FQDN,svc_WebAnalytics,accountPassword,SharePoint Web Analytics service account
svc_SecureStore,svc_SecureStore@domainName.FQDN,svc_SecureStore,accountPassword,Secure Store Application Pool service account
svc_spSTSAcct,svc_spSTSAcct@domainName.FQDN,svc_spSTSAcct,accountPassword,Security Token Service Application
svc_spMetadata,svc_spMetadata@domainName.FQDN,svc_spMetadata,accountPassword,Managed Metadata Service Account
…and now the magical one-line PowerShell command, this needs to run using the Active Directory module for Windows PowerShell.

The Active Directory module for Windows PowerShell in Windows Server® 2008 R2 is a Windows PowerShell module (named ActiveDirectory) that consolidates a group of cmdlets. You can use these cmdlets to manage your Active Directory® domains, Active Directory Lightweight Directory Services (AD LDS) configuration sets, and Active Directory Database Mounting Tool instances in a single, self-contained package.
You can install the Active Directory module by using any of the following methods:

• By default, on a Windows Server 2008 R2 server when you install the AD DS or AD LDS server roles
• By default, when you make a Windows Server 2008 R2 server a domain controller by running Dcpromo.exe
• As part of the Remote Server Administration Tools (RSAT) feature on a Windows Server 2008 R2 server
• As part of the RSAT feature on a Windows 7 computer

Start Active Directory module for Windows PowerShell and type the following:
Import-Csv acc.csv | ForEach-Object { New-ADuser -Path 'OU=Service Accounts,DC=dev,DC=local' -Name $_.samAccountName -samAccountName $_.samAccountName -userPrincipalName $_.userPrincipalName -GivenName $_.cn -description $_.description -PasswordNeverExpires $True -CannotChangePassword $True -Enabled $true -AccountPassword (ConvertTo-SecureString $_.Password -AsPlainText -force)}
in the above script I have an OU called “Service Accounts” and my domain name is “dev.local”