Get count of objects in a directory with PowerShell

A quick post!

Today I started migrating content from an on-premises source to SharePoint Online using ShareGate’s Migration tool (AWESOME TOOL by the way!). I’m about 2 hours in to the migration and I was curious how much content I had to go. I need to get a count of all the objects in the directory. PowerShell to the rescue:

$path = "[paste directory path here]"
$files = gci $path -recurse | Measure-Object
$files.Count

You’ll get a count of all the objects in the directory. This number will help me gauge how long the migration will take. Happy migration!

Powershell hack with IE

I wrote this because I wondered if it could be done. I figured it would be pretty difficult to come up with a Powershell hack with IE but as it turned out it took just a little bingling and this is what I came up with:

start 'http://www.inhifistereo.com'

Start-Sleep -s 5

Get-Process iexplore | Foreach-Object { $_.CloseMainWindow() }

exit

The script opens the browser, waits 5 seconds, then closes the page. Pretty simple I know but I’ll be expanding on this script more in the future. Some possibilities/uses could be:

  • Check a web page for content then send an email depending on what’s found
  • Keep VPN connection open
  • Check if a website is up

I went even farther as to add it to the Task Scheduler and have it run every 30 minutes. There are plenty of blog posts out there outlining how to create a Task in Task Scheduler, but the small hiccup I ran in to was how to run Powershell from the Scheduler.

When you get to the Actions tab add the path to Powershell:

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe

The “Add arguments” section is where you add the command and path to your .ps1 file:

-Command “& [path to your file without brackets]”

The possibilities are pretty endless here. I don’t know if anyone else will find this useful but I know I will use it.

Obligatory SharePoint 2013 Search Powershell post

Maybe you’re still kicking the tires on SharePoint 2013 installing it for the first time. Maybe you’re in the throws of planning your migration. Maybe you’re a consultant who’s been stuck on a SharePoint 2010 project for the last 18 months. Either way, we all have to face the music sooner or later and upgrade to SharePoint 2013. When you do, you’ll have to setup a Search Service. It’s not as bad as you’d think. And if you have at least 3 servers in your farm (1 app and 2 WFEs) then this script will work for you. Without further delay:

#Config Section
$APP1 = "App1"
$WFE1 = "WFE1"
$WFE2 = "WFE1"
$SearchAppPoolName = "SearchServiceAppPool"
$SearchAppPoolAccountName = "domainSearchSvc"
$SearchServiceName = "SharePoint Search Service"
$SearchServiceProxyName = "SharePoint Search Service Proxy"
$DatabaseServer = "DBserver"
$DatabaseName = "SP_Search_AdminDB" 

#Create a Search Service Application Pool
$spAppPool = New-SPServiceApplicationPool -Name $SearchAppPoolName -Account $SearchAppPoolAccountName -Verbose 

#Start Search Service Instance on all Application Server
Start-SPEnterpriseSearchServiceInstance $App1 -ErrorAction SilentlyContinue
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $App1 -ErrorAction SilentlyContinue

#Start Search Service Instance on WFEs
Start-SPEnterpriseSearchServiceInstance $WFE1 -ErrorAction SilentlyContinue
Start-SPEnterpriseSearchServiceInstance $WFE2 -ErrorAction SilentlyContinue

#Create Search Service Application
$ServiceApplication = New-SPEnterpriseSearchServiceApplication -Partitioned -Name $SearchServiceName -ApplicationPool $spAppPool.Name -DatabaseServer $DatabaseServer -DatabaseName $DatabaseName 

#Create Search Service Proxy
New-SPEnterpriseSearchServiceApplicationProxy -Partitioned -Name $SearchServiceProxyName -SearchApplication $ServiceApplication
$clone = $ServiceApplication.ActiveTopology.Clone()

#Set variables for component creation
$App1SSI = Get-SPEnterpriseSearchServiceInstance -Identity $App1
$WFE1SSI = Get-SPEnterpriseSearchServiceInstance -Identity $WFE1
$WFE2SSI = Get-SPEnterpriseSearchServiceInstance -Identity $WFE2

#Create Admin component
New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $App1SSI 

#Create Processing component
New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $App1SSI

#Create Analytics Processing component
New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $App1SSI

#Create Crawl component
New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $App1SSI

#Create query processing component
New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $App1SSI

#Set the primary and replica index location; ensure these drives and folders exist on application servers
$PrimaryIndexLocation = "C:SPSearch"
$ReplicaIndexLocation = "C:SPSearchReplica" 

#We need two index partitions and replicas for each partition. Follow the sequence.
New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $WFE1SSI -RootDirectory $PrimaryIndexLocation -IndexPartition 0
New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $WFE2SSI -RootDirectory $ReplicaIndexLocation -IndexPartition 0
New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $WFE1SSI -RootDirectory $PrimaryIndexLocation -IndexPartition 1
New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $WFE2SSI -RootDirectory $ReplicaIndexLocation -IndexPartition 1

$clone.Activate()

#Verify Search Topology
$ssa = Get-SPEnterpriseSearchServiceApplication
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

This script is actually pretty basic. 90% of the services end up on your App box, while the Index partitions live on your WFEs. You could provision the service on one box or any combination you see fit. That’s the beauty of this model. For me, I like having the Index partition closest to where people will be searching (i.e. the WFEs).

The script should take anywhere from 10-30 minutes to run, maybe longer depending on your hardware. Once done, navigate to your Search Service in Central Admin and this is what you should see in the Search Topology.

Most important thing to remember when using this script is to create the C:SPSearch and C:SPSearchReplica directories on your WFEs PRIOR to running this script. The script will fail if you don’t do this and it’s a pain to cleanup after so create the directories first. I’ll probably write in a check to see if the directories exist – and if they don’t go, ahead and create them – next time I run this script when setting up an environment.

PowerShell v3 & SharePoint 2010

I’m finding more and more that I’m late to the party for some things in SharePoint.

Apparently, SharePoint 2010 isn’t compatible with PowerShell v3.

Basically, when you try to use the SharePoint 2010 Management Shell you’ll be greeted with this:

clip_image001

Once you encounter this lovely error you’ll think you’ve done something horribly wrong. Is something up with your account? Did you break something? Are you losing it?

Nope to all of the above.

To get around this, type: powershell –v 2

Then hit enter. You now have regular ole PowerShell loaded. You’ll have to load the SharePoint snap-in if you want to do anything with SharePoint though. For anyone who may need it, the snap-in is:

Add-PSSnapin Microsoft.SharePoint.PowerShell

You can check out all the details here in this Connect article:

http://connect.microsoft.com/PowerShell/feedback/details/746908/powershell-3-0-and-sharepoint-2010

Hopefully this gets fixed in the next CU.