if($this) { write-host $this }
Script a backup of selected datasources Microsoft DPM 2010
Can be hard to work out this one, here is what worked for us. Our requirement was to back up a selection of datasources from varying protection groups on a daily cycle. The script below works the way we want, it is modified from a snipet we found ont there on google.
##################################################################### # Any script which includes the next two lines can run DPM Scripts # probably need to be running elevated though ... add-pssnapin -name Microsoft.DataProtectionManager.PowerShell -ErrorAction SilentlyContinue $Error.Clear() # For try catch logic to work the way I expect $errorActionPreference = 'Stop' ##################################################################### # # Variables you need to review # ##################################################################### # # The Dpm server we want to work with # $DpmServer="DPM2010.DOMAIN.COM" # enter here the name of your DPM server $storage="Disk" # choose from Disk or Tape $protectionType="LongTerm" # choose from LongTerm or ShortTerm # # # ##################################################################### function DoTheBackups([string] $dpmServer, [string] $pg, [string] $computerName,[string] $ds) { $mypg = get-protectiongroup -dpmservername $dpmServer | where {$_.FriendlyName -ieq $pg} $myds = get-datasource -protectiongroup $mypg | where {$_.Name -ieq $ds -and $_.ProductionServerName -ieq $computerName } if($myds) { write-host "`n`n" "Create recovery point for '$ds' on '$computername' to '$storage'" if ($storage -ieq "Tape") { try { $myjob = new-recoverypoint -datasource $myds -Tape -ProtectionType $protectionType } catch { write-host "`t" $_.Exception.Message } } else { try { $myjob = new-recoverypoint -datasource $myds -Disk -DiskRecoveryPointOption WithSynchronize } catch { write-host "`t" $_.Exception.Message } } if ($myJob) { $jobtype = $myjob.jobtype write-host "`t`t" "Starting the process of $jobtype for tape backup" while (! $myjob.hascompleted ) { write-host "`t`t`t" $myjob.Status start-sleep 5 } if($myjob.Status -ne "Succeeded") { write-error "`t`t" "Job Failed" $pg $ds } Else { Write-host "`t`t" "Job Succeeded" $pg $ds } } else { write-host "Error creating new recovery point for '$ds' on '$computerName'" } } else { write-host "Data source '$ds' on protectiongroup '$pg' not found or not appropriate" } } # # Define what we want this script to do # ##################################################################### function main() { connect-dpmserver $DpmServer | out-null # # Add lines here for each datasource you want to backup # DoTheBackups -dpmserver $DpmServer -pg "PG-Desktops" -computerName "Parsley.domain.com" -ds "User data" DoTheBackups -dpmserver $DpmServer -pg "Protection Group 2 - XPTESTPC1" -computerName "XPTESTPC1.domain.com" -ds "C:\" disconnect-dpmserver $DpmServer | out-null } ##################################################################### # # Run the main script # ##################################################################### main #####################################################################
Another powershell script, Information management policy via script to content types
This was hard to trackdown so I thought I would put it here for others to use. Post the script below into a file e.g. SetPolicy.ps1
Export a policy from Site collection to an xml file, from say, your dev server, put the xml file and the script into the same folder on say, your production server
Fire up a powershell window as admin and run the script.
# SET THESE # $PortalUrl="http://server/webapp" $manifestXml = get-content "Next_Update_Due_Policy.Xml" # The manifest contains an ID $policyFeatureId="af5f1adb-dca9-490a-9bae-b5f6238699c7" # This is the ID from the manifest # # ##################################################### $wa = Get-SPWebApplication $Portalurl $site = Get-SPSite -Identity $portalUrl $contentTypes = @() $contentTypes += "Content type 1" $contentTypes += "Content type 2" $contentTypes += "Content type 3" # Create site collection policy # Import XML into it # try { [Microsoft.Office.RecordsManagement.InformationPolicy.PolicyCollection]::Add($site, $manifestXml) write-host "Created site collection policy" } catch { write-host $_.Exception.Message } $policyCatalog = new-object Microsoft.Office.RecordsManagement.InformationPolicy.PolicyCatalog($site) $SiteCollpolicy = $policyCatalog.PolicyList[$policyFeatureId] # Bind each content type to the policy we just created # $contentTypes % { $thisContentType = $_ Write-host "Bind policy to" $thisContentType $ctype = $site.RootWeb.ContentTypes[$thisCOntentType] try { [Microsoft.Office.RecordsManagement.InformationPolicy.Policy]::CreatePolicy($ctype, $SiteCollpolicy); } catch { write-host $_.Exception.Message } } $site.Dispose() Write-host "Run timer jobs" Get-SPTimerJob ?{$_.Name -match "PolicyUpdateProcessing"} ?{$_.Parent -eq $wa} Start-SPTimerJob Get-SPTimerJob ?{$_.Name -match "DocIdEnable"} ?{$_.Parent -eq $wa} Start-SPTimerJob Get-SPTimerJob ?{$_.Name -match "DocIdAssignment"} ?{$_.Parent -eq $wa} Start-SPTimerJob
So whats happening then;
- Read the exported policy xml into a variable
- Add the previously exported policy xml to a new SiteCollection policy
- Get the site collection policy catalog
- From there get the policy we just Added
- Now for each content type in the earlier created array of content type names
- Bind the policy to the content type
- Finally run a few chosen timer jobs to make it all hang together
Enjoy.
Script the DCOM fix in SharePoint
I got fed up with fixing this so I put together a powershell script to sort
it all out for me.
You will need to install SetAcl and DcomPerm.
Paste the script below into a file e.g. FixDcom.ps1
Fire up a powershell window (As Administrator) and execute the script
As ever, all at your own risk.
$PortalSiteOwner="domain\username" $PortalAccount="domain\username" $SPFarmAccount="domain\username" $SetAcl="WhereYouInstalledSetAcl.exe" $backupFileName="$here\RegPerms-Dconfig.bak" $RegKeyOwner="$PortalSiteOwner" # SETACL # # Backup the existing perms # $args = "-on", "HKCR\AppID\{61738644-F196-11D0-9953-00C04FD919C1}", "-ot", "reg", "-actn", "list", "-lst", "f:sddl;w:d,s,o,g;i:y;s:b", "-bckp", "$backupFileName" & $SetAcl $args # Take ownership # $args = "-on", "HKCR\AppID\{61738644-F196-11D0-9953-00C04FD919C1}", "-ot", "reg", "-actn", "setowner", "-ownr", "n:$RegKeyOwner;s:n" & $SetAcl $args # Assign full control # $args = "-on", "HKCR\AppID\{61738644-F196-11D0-9953-00C04FD919C1}", "-ot", "reg", "-actn", "ace", "-ace", "n:$RegKeyOwner;p:full" & $SetAcl $args # DCOMFIG # Write-Host "THIS WILL FAIL IF YOU DO NOT HAVE REGISTRY ACCESS TO" Write-Host "HKCR:\AppID\{61738644-F196-11D0-9953-00C04FD919C1} REGISTRY KEY" $argz = @( "-al", "{61738644-F196-11D0-9953-00C04FD919C1}", "set" , "__USER__HERE__" ,"permit", "level:l") $argz[3] = "$SpfarmAccount" & "$AssetsPath\dcomperm.exe" $argz $argz[3] = "$PortalAccount" & "$AssetsPath\dcomperm.exe" $argz # Restore original permissions # $args = "-on", "HKCR\AppID\{61738644-F196-11D0-9953-00C04FD919C1}", "-ot", "reg", "-actn", "restore", "-bckp", "$backupFileName" & $SetAcl $args
So this is what it is doing;
- Use SetAcl to make a backup of the registry permissions on the …919C1 registry key
- Use SetAcl to take ownership of the …919C1 registry key
- Use SetAcl to assign full control of the …919C1 registry key
- Use Dcomperm to Grant local activation to SP Farm account
- Use Dcomperm to grant loccal activation to Portal app pool account
- Use SetAcl to restore the originla permissions to the … 919C1 registry key
Enjoy.
>Dcom {61738644-F196-11D0-9953-00C04FD919C1} Error
>This is still an issue, surely the SharePoint installer should be sorting this one out by now ? Windows 2008 R2 – Steps to fix
- Load REGEDIT Find HKEY_CLASSES_ROOT\AppID\{61738644-F196-11D0-9953-00C04FD919C1}
- Right click the key — Choose permissions — Choose Advanced
- Make yourself the owner
- Switch back to permissions
- Add yourself as full control
- Click apply
- Leave regedit open in order to revert permissions and ownership later
- Now load component Services
- Find DCOM CONFIG — IIS WAMREG ADMIN SERVICE
- Right click — Properties — Security
- Set your Launch and activation permissions the way you want
- Typically SPFarm and Web app pool accounts Local activation is required
- Now go back to REGEDIT and remove your Full control permission
- Hit apply
- Now revert the key owner back to NT SERVICE\TRUSTEDINSTALLER
- Close Regedit
All should new work as expected
>Nice powershell to display Managed, crawled and mapped metadata properties in SharePoint 2010
>
So on your SharePoint server, paste the script below into powershell_ISE or a script file e.g. PropListing.ps1 and edit the $searchAppName variable to be the exact name of your search application. ![]()
Run the script and the output should explain itself.
$PSSnapin = Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$searchAppName = “Your name Enterprise Search Service Application”
$app = Get-SPEnterpriseSearchServiceApplication -identity $searchAppName
$cats = Get-SPEnterpriseSearchMetadataCategory -SearchApplication $app
$ManagedMapped = @{}
Write-Host “Categories”
$cats | % {
$cat = $_
Write-host “`t” $cat.name
$crawledprops = $cat.GetAllCrawledProperties()
Write-host “`t`t” “Crawled properties”
$crawledprops | % {
$crawledProperty = $_
Write-Host “`t`t`t” $crawledProperty.name
$mappedManagedProps = $crawledProperty.GetMappedManagedProperties()
if($mappedManagedProps.Count -gt 0) {
Write-Host “`t`t`t`t” “Mapped to managed property(s)”
$mappedManagedProps | % {
$mappedManagedProperty = $_
Write-Host “`t`t`t`t`t” $mappedManagedProperty.name
if(-not $ManagedMapped.ContainsKey($mappedManagedProperty.name)) {
# record this prop for later
$ManagedMapped.Add($mappedManagedProperty.name,$mappedManagedProperty)
}
}
}
}
}
# Find unmapped managed properties
Write-host “Listing of unMapped Managed properties”
Write-host “————————————–”
$allManProps = $app.GetManagedProperties()
$allManProps | % {
$allprop = $_
if(-not $ManagedMapped.ContainsKey($allprop.name)) {
Write-host “`t” $allProp.name
}
}
No warranties implied or otherwise ![]()
>SharePoint Content pushdown
>This is a bit of a challenge.
Create and deploy a content type to Moss, lets say a “person” content type. Which consists of a couple of columns, Name and Address.
Then later you decide you need “phone number” …..
Simple, add an additional site column and re deploy the feature.
This is fine for any new “Person” you create, however all your existing “Person” will not allow you to add the “Phone number”
Enter the need for Content type push down.
Simple, go into site settings and manage site content types, click “propagate down” and all is well.
Unless you do scripted deployments that is.
So along comes Søren Nielsen and Gary Lapointe with a nice stsadm command to fix this issue for us.
For me though their solution has a couple of issues.
It seems to mix up display and internal name, causes me to lose (Hide) content, this is bad
It dosent “Seem” to fix up “list column title” which it may have messed up in the “List content type”
So if you have lost content by using “propagate content type changes” you are not alone, and if like me yours is just hidded by Gary’s issues, you can get it back.
I wont post the code here as its quite large and work in progress.
Drop me a mail if you are suffering from this and I’ll let you have the code. (At your own risk of course
)
>SPWeb
>This is a fun object, consider this
SPSite site = new SPSite(“legitimate site collection url”) ;
SPWeb webA = site.OpenWeb(“Some bogus url”) ;
SPWeb webB = site.AllWebs["some bogus url"] ;
You would expect this code to throw two exeptions, you would be wrong.
Well you would expect webA and webB to at least be null, you would be wrong.
Apparently (not for the sake of consistency )
if(webA.Exists())
Do stuff with webA
Is the prescribed way to deal with this, how many of us have seen code like the following scattered all over blogs and such
if (webA != null) ….
Well, you live and learn.
>PSCONFIG is your pal
>Having some issues with scripting psconfig at the moment also. We have written some scripts based lossely on a ms white paper and posts from Spence and a few others (Plus previous experience of doing a simmilar scripting job for MS)
Our aim is to create a standalone script which can be run from a TFS build service, the script should take an Operating system only windows server and take it to SharePoint, SSP, Central admin a couple of web apps and various custom visual studio peices.
It should do this every night (CI, Continuous integration) and furthermore it should do all this from a tfs build box accross the wire to the deploy box.
For the remoteing we are using WinRs and a fine tool it is too.
Except, it dosent work in a couple of notable instances.
WinRs psconfig to create config DB fails
WinRs to run a powershell script to re set a hyperv machine to a particular checkpoint fails.
Both of these two work when executed locally they just fail when run over winRs. The latter works via telnet (for those looking for a solution that works)
I would welcome discussing this with anyone going through the same pain.
I will follow this up once PSS get me a definitave answer on if this is supported scenario or not.
Update (October 2009)
Seems that this scenario is not supported, according to MS PSS.
However, as is often the case, needs must …
A solution: May or may not work for you.
Configure Integration macjhine to automatically log in as userx and boot time (You will now have a fully logged in session)
Create a login script which copies you integration script locally and runs it
Not Elegant, but it works.
>What you need to know about advice …
>In my last posting I passed on some advice I got from a collegue relating to december cumulative updates for SharePoint server 2007.
Well, you live and learn, following that advice caused some issues with subsequent updates in my case.
So the fact is, your mileage may vary. My mileage turned into a full restore from backup, re download the offending updates (now magically working as expected) re install and all is now well, moral, always back these things up before any major changes.
Thank god for Hyperv checkpoints.