Recently I found a way to dynamically update Microsoft Word text placeholders with PowerShell script. Because DOCX files are ZIP archive we can extract to a TEMP folder to update the internal XML document text. From there, bundling to a new ZIP archive and renaming DOCX enable us to deliver the final DOCX version to users.
I recently needed to parse a large CSV text file and break it into smaller batches. Parsing text with PowerShell can easily be done. The trick here was to manage two pointers $line (within original large text file) and $i (iterate current up to next break threshold). The first CSV line with column headers from the original parent text file is preserved in all child CSV files.
When migrating from MySite on-premise to OneDrive in the cloud, Quick Links are not included by third party utilities (i.e. ShareGate). However, with PowerShell we can export the original raw CSV data and provide a list of links to end users. They can bookmark or add to Office 365.
Tried of waiting for Backup-SPSite / Restore-SPSite? Me too. Why not clone the SQL content database with SQL backup and restore?
Well, SharePoint requires every Site Collection on a given to have a unique GUID. When we clone a SQL content database and attempt Mount-SPContentDatabase an error comes up that the GUID already exists on the local farm. No bueno.
Why not generate and replace the GUID? In theory, we can UDPATE the SQL database internally with fresh new GUID numbers and SharePoint would recognize as new site collections. No conflict. That is exactly what the PowerShell below does. By walking the schema, finding “SiteID” and “tp_SiteID” columns, and replacing the old GUID with a new GUID.
The larger the site collection, the better this works on time savings. SQL internally can backup and restore a database much faster than waiting for Backup-SPSite/Restore-SPSite to export/import binary data across the wire to the SharePoint front end file system.
In the example below you can see a brand new team site created with GUID “82dad5a8-aa6e-4480-a10e-16cd2597c18b” in a dedicated SQL content database, taken offline, updated with PowerShell to replace old GUID with new GUID “0f59c302-92ea-4fac-b32b-799f3dd41264” and then successfully consumed again.
NOTE – You still need a unique URL, so be sure to run Mount-SPContentDatabase against a secondary web application.
NOTE – This is completely unsupported. Use at your own risk. Worked well on Dev and Test environments for me.