Bulk reset of passwords

Recently, I had to reset a whole bunch of passwords. This can be easily done via PowerShell.

$Excludes = @('user1', 'user2')

$Password = ConvertTo-SecureString -AsPlainText -Force 'mypassword'

$SearchBase = "OU=Some OU,DC=Some DC,DC=Some DC"

Import-Module ActiveDirectory

Get-ADUser -Filter * -SearchBase $SearchBase | Where-Object {$Excludes -notcontains $_.SamAccountName} | Set-ADAccountPassword -NewPassword $Password

Then to check what was done:

Get-ADUser -Filter * -Properties SamAccountName, PasswordLastSet | Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet -Descending

Extracting data from SQL Azure using Powershell

I have a SQL Website that is logging some debug output to a SQL Azure DB Linked Resource. In order to do some quick troubleshooting, I tried using the Manage interface in Azure, however it is lacking a way to export the data. I could manually copy and paste out database rows and columns, but that is a pain. I don't have SQL 2013 Management Studio and just want a lightweight way for me to access my databases.

I ended up doing this with Powershell:

$datasource=mydatasource
$database=mydatabasename
$userid=myuserid
$password=mypassword
$CommandText=some_sql_query


$connectionString = "Data Source=$datasource;Initial Catalog=$database;User ID=$userid;Password=$password;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"
$SqlCmd=New-Object System.Data.SqlClient.SqlCommand($CommandText)
$SqlCmd.Connection=New-Object System.Data.SqlClient.SqlConnection($ConnectionString)

$SqlAdapter=New-Object System.Data.SqlClient.SqlDataAdapter($SqlCmd)
$DataSet=New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
...
I can then get at the data through $DataSet.

I can also get the connection string though the Windows Azure console and go to SQL Databases, select my database, select "View SQL Database connection strings for ADO .Net, ODBC, PHP, and JDBC", copy the ADO.NET connection string, and replace "Server" with "Data Source", "Database" with "Initial Catalog", and "{your_password_here}" with my password.

Error: The configuration section 'microsoft.applicationServer' cannot be read because it is missing a section declaration

Recently, I have been trying to install some code on a brand new server running Windows 2008 R2 SP1 and .NET 4.0. However, I kept running into the following error: Error: The configuration section 'microsoft.applicationServer' cannot be read because it is missing a section declaration

There are many resources out there talking about adding various things. It turns out that what I was missing was AppFabric.

Ouch! I wasted a lot of time on that one.

Enabling incoming email on SharePoint 2013

I am running SharePoint 2013 RTM on one of my demo servers and want to enable incoming email. The configuration is exactly the same as in SharePoint 2010:
Setup your SMTP server to receive email
Set "Enable sites on this server to receive e-mail" to Yes
Verify firewall settings to allow connections to port 25

However, after checking all this, my incoming email was still not making it into my lists. I can see the incoming email message sitting in the C:\inetpub\mailroot\Drop folder and it is not being processed.

By chance, I decided to set "Enable sites on this server to receive e-mail" to No, save and then back to Yes. Then miraculously, the incoming email is now being processed. I have now seen this exact behaviour several times with my SharePoint 2013 instances.

SharePoint 2013 About Me page timing out

For some reason, all of a sudden, I am no longer able to access my "About Me" page (/my/Person.aspx) on one of my SharePoint 2013 demo servers. I can access the "About Me" page for everyone else and everyone else can also access their "About Me" page, but no one can access mine. It seems to spin for a long time and then time out. The only thing in ULS is an aborted thread exception.

Finally, I tried accessing the edit page of my "About Me" using /my/_layouts/15/EditProfile.aspx, hit save without even changing anything and magically, I can see my "About Me" page again.

Very bizarre.

Crawling root web of a site collection

I was recently trying to troubleshoot a search problem with my application. It turned out that there was a list at the root web of a site collection that was not being indexed by search.

$ssa = Get-SPEnterpriseSearchServiceApplication | Where-Object {$_.Name -eq "FAST Search Query Service Application"}

$logViewer = New-Object Microsoft.Office.Server.Search.Administration.LogViewer($ssa)

$urlProperty = [Microsoft.Office.Server.Search.Administration.CrawlLogFilterProperty]::Url

$stringOperator = [Microsoft.Office.Server.Search.Administration.StringFilterOperator]::Contains

$crawlLogFilters = New-Object Microsoft.Office.Server.Search.Administration.CrawlLogFilters

$searchUrl = 'my URL'

$crawlLogFilters.AddFilter($urlProperty, $stringOperator, $searchUrl)

$i=0

$urls = $logViewer.GetCurrentCrawlLogData($crawlLogFilters, ([ref] $i))

$urls

Then I checked with a colleague and it turns out that all I needed to check was Site Actions->Site Settings->Search and offline availability. The "Allow this site to appear in search results" was set to No. 

SharePoint connection to SQL Server

This is a big <facepalm> since it should have been pretty obvious.

I was trying to install a new SharePoint 2013 farm connecting to a brand new SQL Server 2008 R2. In the SharePoint Products Configuration Wizard, it asks for the SQL connection and kept rejecting my credentials. Checking on the SQL server side, I could not see any connection attempts. I used the following to test with Powershell

$CommandText = "SELECT @@VERSION"
$SqlCommand=New-Object System.Data.SqlClient.SqlCommand($CommandText)
$ConnectionString='Data Source=SQL1;Initial Catalog=master;Integrated Security=SSPI'
$SqlCommand.Connection=New-Object System.Data.SqlClient.SqlConnection($ConnectionString)
$SqlAdapter=New-Object System.Data.SqlClient.SqlDataAdapter($SqlCommand)
$DataSet=New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)

I kept getting all sorts of errors. It turns out the Windows Firewall on my SQL server was not allowing port 1433. Argh - wasted a couple of hours tracking this one down.