Tuesday, June 21, 2016

Running PowerShell on MOSS 2007

Running PowerShell on MOSS 2007


  1. If you are running MOSS 2007 on Windows Server 2003 the you have to download and install PowerShell fromhttp://support.microsoft.com/kb/968930. Windows Server 2008  natively supports PowerShell.
  2. Set the  Execution Policy to ‘RemoteSigned’. You can check it by running ‘Get-ExecutionPolicy’ cmdlet 
    The default execution policy for PowerShell is “Restricted” (commands only, not scripts)
         
# All scripts running locally are allowed
Set-ExecutionPolicy RemoteSigned
This means downloaded scripts must be signed by a trusted publisher before they can be run.
     3. You need to load the SharePoint assemblies with the following command
#    Load the SharePoint assemblies
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
A bunch of PowerShell scripts are available at http://www.powershell.nu/2009/09/08/moss-2007-script-collection

Ref: https://blogs.technet.microsoft.com/praveenh/2013/01/21/running-powershell-on-moss-2007/ 

Ex:1 Retrieve the list of Content Types in MOSS 2007 using PowerShell
MOSS 2007 
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | out-null
Write-host ".."
Write-host ".."
Write-host "Get a list of Content types"
$site = new-object Microsoft.SharePoint.SPSite("http://spweb/extend"); # specify url here
foreach ($web in $site.AllWebs) { 
  $ctypes = $web.ContentTypes
  foreach ($ctype in $ctypes) {
  $usages = [Microsoft.Sharepoint.SPContentTypeUsage]::GetUsages($ctype) 
    foreach ($usage in $usages) { 
    Write-Host $web.Name + "," + $ctype.Name + "," + $usage.Url 
    } 
  }
}

Ex:2 

MOSS 2007 – Find the default view url for all lists in a web app using PowerShell


param
(
    $url = $(Read-Host -Prompt "WebApp Url")
)
# Default View for lists in All Sites
# Lookup Web Application as specified in the command line parameter
$wa = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($url) 
# Create an array 
$sites =@()
Write-Output("`nProcessing sites...`n") 
# Loop through all site collections in the web application
foreach($site in $wa.Sites)
{
    foreach ($s in $site)
    {
        $spWeb = $s.openweb()
            foreach($list in $spweb.lists)
            {
                Write-Host "list:", $list.defaultview.url
            }
    }
}



Thursday, October 22, 2015

“The signin method you’re trying to use isn’t allowed” – Windows Server 2012 - Adding AD Accounts to local users and groups

“The signin method you’re trying to use isn’t allowed” – Windows Server 2012

During the work with my first book Beginning SharePoint 2013 Workflows, I have been using a Hyper-V VM running SharePoint 2013 on Windows Server 2012. I created a workflow demo where an admin started a workflow that assigned a task to a standard user. But then when I tried to login as this user, I received the following message in the login window:  “The signin method you’re trying to use isn’t allowed. For more info contact your network administrator.”
This behavior is  probably intended by Microsoft. By default, only administrators should login locally to the server where Windows Server 2012 is running. The server is not supposed to be someone’s workstation! This is a valid and understood statement in a production environment since otherwise it could become the security hole of the century!  But I’m running  WS2012 with SharePoint 2013 on a VM hosted on my Windows 8 laptop, and I want to switch users locally, so there should be a solution for this. The good news are, you can bypass this restriction, but you have to dig deep into the Group Manager hierarchy to find the correct place to add the fix. Here’s how:
Log in as the administrator on the server, then start the Group Policy Management Editor by running the  gpmc.msc command from PowerShell or the Command Line window.
1. In the Group Policy Management window on the left hand side, select Group Policy Management.
Pic1
2. Click to expand the  Forest<your domain name> tree node.
3. Click Domains.
4. Select your domain name.
5. Click Group Policy Objects.
Pic2
6. In the right-hand window, double-click Default Domain Controllers Policy.
7. Right-click Default Domain Controllers Policy and Select Edit.
8. In the Group Policy Management Editor window, click Default Domain Controllers Policy.
9. Click Computer Configuration, and then click Policies.
10. Click Windows Settings, and then click Security Settings.
Pic3
11. Click Local Policies and then click User Rights Assignments.
12. In the right pane, click Allow log on locally.
Pic4
12. Click the Add User or Group button.
13. In the Add User or Group dialog,  enter the name to be added or click Browse.. to search for a name.
Pic5
14. Click OK .
15. Repeat steps 12-14 if you want to add more users.
16. Click OK to Close the Allow log on locally Properties dialog, and then click Close several times to Close the remaining open Windows.
17. Run the following command in Powershell or the Command Window to activate the policy changes:
gpupdate /force.
By running this rather messy procedure,  I was able to login to Windows Server 2012 locally using a standard user name. Hopefully there are easier ways to achieve this,  so if anyone reads this post and knows anything, please don’t hesitate to add a comment!
Ref Link: http://www.sharepointviking.com/the-signin-method-youre-trying-to-use-isnt-allowed-windows-server-2012/#comment-690 

Friday, September 18, 2015

The specified user username is a local account. Local accounts should only be used in stand alone mode error in SharePoint 2013

Thursday, September 10, 2015

Missing server file or server configuration issues. Web part Errors:

Missing server file or server configuration issues.
Web part Errors:
The following web part(s) are referenced by the content, but they are not installed on the web server
•Id = 72818beb-d38f-ce20-ad03-17a569674760, Type = Unknown, Reference = 29, Status = Missing             
•Id = b0361b90-8e73-425f-bcbc-2b2469198a00, Type = Unknown, Reference = 14, Status = Missing             
•Id = 19060b95-1c73-5a5b-875c-2e2c7d7cd355, Type = Unknown, Reference = 4, Status = Missing             
Steps to fix the errors
1.Logon to Database server and Run following SQL query on the content database for the Support site:
SELECT * FROM [WebParts] WITH(NOLOCK)where tp_WebPartTypeId =’ID’             
Example: SELECT * FROM [WebParts] WITH(NOLOCK)where tp_WebPartTypeId ='72818beb-d38f-ce20-ad03-17a569674760'             
            
From the results pane copy the tp_PageUrlID . These are the ids of the urls which has reference to the missing webparts .
2.Now run following query:
SELECT * FROM Alldocs WITH(NOLOCK)where id='80A251DD-1452-4199-A0BA-05120A7286EC'            
(ID is the value of the tp_PageURLID)
You will get DirName and LeafName corresponding to that PageURLID
3.Repeat step-2 for all the PageURL Ids to get complete URLs for a particular webpart ID. Step-1 and Step-2 needs to be performed multiple times to get a list of all the URLs where we need to fix the webpart error.
4.Now go to the URL, example :http://abc.amd.com/test/pages/test.aspx?contents=1
5.Check-out the page , delete the error web part and check-in/publish the page
6.To test if the issue is fixed run the below query again:
SELECT * FROM Alldocs WITH(NOLOCK)where id='80A251DD-1452-4199-A0BA-05120A7286EC'
again.
You should not get any results if all the URLs are fixed.

Ref Link: https://amritatalreja.wordpress.com/2011/08/02/preupgradecheck-errors-part-1/

How to Remove Missing WebPart during SharePoint Upgrade

If you are upgrading SharePoint 2007 to SharePoint 2010 and getting “MissingWebPart” error when using the Test-SPContentDatabase cmdlet in PowerShell, this tip will help you diagnose the issue.
Following is the original error:
Category: MissingWebPart
Error: True
UpgradeBlocking : False
Message: WebPart class [8c8bca43-cbc1-da50-d518-54614c79b3f5] is referenced [1] times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part.
Remedy: One or more web parts are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
As you can see, the error message gives you a WebPart GUID [8c8bca43-cbc1-da50-d518-54614c79b3f5] and the name of the content database [WSS_Content]. What we need to find out is on which page it is referenced in the database. For this we can run a SQL SELECT query on the “AllDocs” table in the content database exhibiting the problem. For example, you would run the following command to find details of the web part with the class ID “8c8bca43-cbc1-da50-d518-54614c79b3f5″:
select AllDocs.SiteId, WebId, Webs.Title as‘Web Title, ListId, DirName, LeafNamefrom AllDocs innerjoin WebParts on AllDocs.Id = WebParts.tp_PageUrlID innerjoinWebs on AllDocs.WebId = Webs.Id where WebParts.tp_WebPartTypeID =’8c8bca43-cbc1-da50-d518-54614c79b3f5′
It will list a very useful output, as shown in this example:
To remove the web part, type the page URL in the browserformat as “http://<SiteURL>/<DirName>/<Leafname>?contents=1″. In this example, type the following URL in the browser:
http://mossdev/default.aspx?contents=1
The screenshot below shows a web part maintenance page, you can delete the missing WebParts on the page.



Ref Link: http://www.boostsolutions.com/blog/how-to-remove-missing-webpart-during-sharepoint-upgrade/

Friday, September 4, 2015

Download a WSP Solution File from SharePoint 2010 Farm with PowerShell

Download a WSP Solution File from SharePoint 2010 Farm with PowerShell



$farm = Get-SPFarm
$file = $farm.Solutions.Item("extendeddiagnosticproviders.wsp").SolutionFile
$file.SaveAs("c:\temp\extendeddiagnosticproviders.wsp")

Tuesday, December 16, 2014

Migrate from classic-mode to claims-based authentication in SharePoint 2013

Summary:Convert SharePoint 2010 Products or SharePoint 2013 classic-mode web applications to claims-based authentication or create new claims-based web applications in SharePoint 2013.
Claims-based authentication is an essential component to enable the advanced functionality of SharePoint 2013. To move classic-mode web applications from SharePoint 2010 Products to SharePoint 2013, you can convert them to claims-based web applications within SharePoint 2010 Products, and then migrate them to SharePoint 2013. The procedures in this article illustrate various supported scenarios.
The Windows PowerShell Convert-SPWebApplication cmdlet in SharePoint 2013 converts classic-mode web applications to claims-based web applications.
WarningWarning:
After you convert a web application to claims-based authentication, you cannot revert it to classic-mode authentication.

Convert SharePoint 2010 Products classic-mode web applications to claims-based authentication in SharePoint 2010 Products and then upgrade to SharePoint 2013

In SharePoint 2010 Products, complete the following procedure to convert an existing web application to claims-based authentication. After you convert the web application to claims-based authentication, complete the additional step to migrate the web application to SharePoint 2013. To complete this procedure, you need the following information:
  • The URL of the web application that you are converting: http://yourWebAppUrl
  • A user account to set as a site administrator: yourDomain\yourUser
To convert a SharePoint 2010 Products web application to claims-based authentication
  1. Verify that you have the following memberships:
    • securityadmin fixed server role on the SQL Server instance.
    • db_owner fixed database role on all databases that are to be updated.
    • Administrators group on the server on which you are running Windows PowerShell cmdlets.
    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
    • Add memberships that are required beyond the minimums above.
    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.
  2. From the Windows PowerShell command prompt, type the following to set the specified user account as an administrator for the site:
    $WebAppName = "http://<yourWebAppUrl>"
    $wa = get-SPWebApplication $WebAppName
    $wa.UseClaimsAuthentication = $true
    $wa.Update()
    
    Where:
    • <yourWebAppUrl> is the URL of the web application.
  3. From the Windows PowerShell command prompt, type the following to configure the policy to enable the user to have full access:
    $account = "yourDomain\yourUser"
    $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
    $wa = get-SPWebApplication $WebAppName
    $zp = $wa.ZonePolicies("Default")
    $p = $zp.Add($account,"PSPolicy")
    $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
    $p.PolicyRoleBindings.Add($fc)
    $wa.Update()
    
    For more information, see Get-SPWebApplication.
  4. From the Windows PowerShell command prompt, type the following to perform user migration:
    $wa.MigrateUsers($true)
    
  5. After user migration completes, type the following from the Windows PowerShell command prompt to perform provisioning:
    $wa.ProvisionGlobally()
    
    For more information, see New-SPClaimsPrincipal.
    NoteNote:
    We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.
After you complete the previous procedures, you might experience one or more of the following issues:
  • Users who submit valid credentials when accessing the migrated web application might be notified that they do not have permissions. If this occurs, theportalsuperuseraccount property and the portalsuperreaderaccount property of the web application were probably configured prior to migration. If this is the case, update the portalsuperuseraccount property and the portalsuperreaderaccount property to use the new claims-based account name. After migration, you can find the new claims-based account name in the web application policy for the migrated web application.
  • If existing alerts are not invoked after migration, you might have to delete and recreate the alerts.
  • If Search crawl does not function on the web application after migration, make sure that the Search crawl account lists the new converted account name. If the new converted account name is not listed, you must manually create a new policy for the crawl account.
To migrate a claims-based SharePoint 2010 Products web application to SharePoint 2013
  1. In SharePoint 2013, create a claims-based web application. For more information, see Create claims-based web applications in SharePoint 2013.
  2. Attach the two existing SharePoint 2010 Products content databases to the newly created SharePoint 2013 claims-based web application. For more information, seeAttach or detach content databases in SharePoint 2013.
    NoteNote:
    When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 claims-based web application, the databases will be upgraded to the SharePoint 2013 database format. You have to verify that the content databases work correctly after you attach them.

Convert SharePoint 2010 Products classic-mode web applications to SharePoint 2013 claims-based web applications

In SharePoint 2013, complete the following procedure to convert an existing SharePoint 2010 Products classic-mode web application to a SharePoint 2013 web application that uses claims-based authentication.
To convert a SharePoint 2010 Products classic-mode web application to a SharePoint 2013 claims-based authentication
  1. Verify that you have the following memberships:
    • securityadmin fixed server role on the SQL Server instance.
    • db_owner fixed database role on all databases that are to be updated.
    • Administrators group on the server on which you are running Windows PowerShell cmdlets.
    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
    • Add memberships that are required beyond the minimums above.
    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.
  2. In the SharePoint 2013 environment, on the Start menu, click All Programs.
  3. Click Microsoft SharePoint 2013 Products.
  4. Click SharePoint 2013 Management Shell.
  5. Change to the directory where you saved the file.
  6. At the Windows PowerShell command prompt, type the following command:
    New-SPWebApplication -name "ClassicAuthApp" -Port 100 -ApplicationPool 
    "ClassicAuthAppPool" -ApplicationPoolAccount (Get-SPManagedAccount 
    "<domainname>\<user>")
    
    Where:
    • <domainname>\<user> is the domain to which the server belongs and the name of the user account.
  7. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 classic-mode web application. For more information, see Attach or detach content databases in SharePoint 2013.
    NoteNote:
    When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 classic-mode web application, the databases are upgraded to the SharePoint 2013 database format. You have to verify that the content databases work correctly after you have attached them.
  8. From the Windows PowerShell command prompt, type the following:
    Convert-SPWebApplication -Identity <yourWebAppUrl> -To Claims 
    -RetainPermissions [ -Force]
    
    
    Where:
    • <yourWebAppUrl> is the URL of the web application.
    NoteNote:
    Convert-SPWebApplication converts the web application to claims-based authentication. You have to verify that the users can access the web application after you have converted it.
  9. If necessary, attach a third SharePoint 2010 Products content database to the new SharePoint 2013 classic-mode web application, and verify that the content database working correctly after you have attached it.
  10. From the Windows PowerShell command prompt, type the following:
    Convert-SPWebApplication -Identity yourWebAppUrl -To Claims 
    -RetainPermissions [ -Force]
    
Verify that users can access the web application after you have converted it to claims-based authentication.
NoteNote:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Convert SharePoint 2013 classic-mode web applications to claims-based web applications

In SharePoint 2013, complete the following procedures to first create a classic-mode Web application, and then convert it to claims-based authentication.
To create a classic-mode Web application in SharePoint 2013
  • Verify that you have the following memberships:
    • securityadmin fixed server role on the SQL Server instance.
    • db_owner fixed database role on all databases that are to be updated.
    • Administrators group on the server on which you are running Windows PowerShell cmdlets.
    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
    • Add memberships that are required beyond the minimums above.
    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.
  • From the Windows PowerShell command prompt, type the following:
    New-SPWebApplication -Name <Name> 
    -ApplicationPool <ApplicationPool>
    -AuthenticationMethod <WindowsAuthType>
    -ApplicationPoolAccount <ApplicationPoolAccount>
    -Port <Port> -URL <URL>
    
    Where:
    • <Name> is the name of the new web application that uses classic-mode authentication.
    • <ApplicationPool> is the name of the application pool.
    • <WindowsAuthType> is either “NTLM” or “Kerberos”. Kerberos is recommended.
    • <ApplicationPoolAccount> is the user account that this application pool will run as.
    • <Port> is the port on which the web application will be created in IIS.
    • <URL> is the public URL for the web application.
    NoteNote:
    For more information, see New-SPWebApplication.
    NoteNote:
    After you successfully create the web application, when you open the Central Administration page, you see a health rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode authentication.
To convert a SharePoint 2013 classic-mode web application to claims-based authentication
  • From the Windows PowerShell command prompt, type the following:
    Convert-SPWebApplication -Identity "http:// <servername>:port" -To Claims
    -RetainPermissions [-Force]
    
    Where:
    • <servername> is the name of the server.
Verify that users can access the web application after you have converted it to claims-based authentication.
NoteNote:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Migrate SharePoint 2010 Products classic-mode web applications to SharePoint 2013 classic-mode web applications

In SharePoint 2013, complete the following procedure to create a classic-mode web application, and then migrate an existing SharePoint 2010 Products classic-mode Web application to SharePoint 2013.
To migrate a SharePoint 2010 Products classic-mode web application to SharePoint 2013
  1. Verify that you have the following memberships:
    • securityadmin fixed server role on the SQL Server instance.
    • db_owner fixed database role on all databases that are to be updated.
    • Administrators group on the server on which you are running Windows PowerShell cmdlets.
    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
    • Add memberships that are required beyond the minimums above.
    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.
  2. From the Windows PowerShell command prompt, type the following:
    New-SPWebApplication -name "ClassicAuthApp" -Port 100 -ApplicationPool 
    "ClassicAuthAppPool" -ApplicationPoolAccount (Get-SPManagedAccount 
    "<domainname>\<user>")
    
    Where:
    • <domainname>\<user> is the domain to which the server belongs and the name of the user account.
  3. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 classic-mode web application. Verify that the content databases work correctly after you have attached them. For more information, see Attach or detach content databases in SharePoint 2013.
For more information, see New-SPWebApplication and Get-SPManagedAccount.
NoteNote:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.