Today’s one liner is all about how to search file contents in Powershell, recursively. Bring on the code!
Get-ChildItem -recurse -filter *.cs | Select-String -pattern “SqlConnection” | group path | sort count | select name > sqlconnection.txt
First, let’s just get all C# source files: Get-ChildItem -recurse -filter *.cs
Second, let’s select all lines with our search string: Select-String -pattern “SqlConnection”
Third, let’s group all the matchinfo objects returned by path: group path
Fourth, let’s sort the grouping objects by count ascending: sort count
Fifth, let’s select only the name (full file path): select name
Finally, let’s pipe it into a file: > sqlconnection.txt
Yay! Easy and simple. I’m going to turn this into a function that I can have at the ready.
I found a really great article about using the TFS Client dll’s here. However, that only worked for VS2013. I had to fix it for VS2015.
For some interesting reason, they are no longer GACing the assemblies, nor are they in a default location. Now they are sym-linked to the existing version.
Here is my example PowerShell code:
$vs2015Path = “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.Client.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.Common.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.Build.Client.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.Build.Common.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.WorkItemTracking.Client.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.VersionControl.Client.dll”
Add-Type -Path “$vs2015Path\Microsoft.TeamFoundation.ProjectManagement.dll”
I frequently need to figure out who the owner of a computer object is in Active Directory.
Enter PowerShell to the rescue!
Easy as pie. Here is the full code for you to use.
$oADObject = Get-ADComputer <ComputerName> -Properties *
$oAceObj = Get-Acl -Path (“ActiveDirectory:://RootDSE/” + $oADObject.DistinguishedName);
Gist Link: https://gist.github.com/dalehhirt/3f03b9ee27a245933e1a
My operations team runs System Center Operations Manager 2012 R2 internally.
I host the OperationsManager database on a SQL Server 2012 Availability Group, and for the most part, it works well. However, for space reasons, we needed to move the Data Warehouse database to its own server backed by SAN storage.
After following this guide (https://technet.microsoft.com/en-us/library/hh268492.aspx), the database was successfully moved, and the data is flowing correctly. In addition, all reporting is working as expected. It was moved from scomsql (SQL 2012 Availability Group) to scomsql3 (standalone instance).
Everything worked out except for the Get-SCOMDataWareHouseSetting PowerShell cmdlet. It would return the name of the old server.
To find the current value, I ran the following:
And now it returns the correct value.
Update: due to the vagaries of WordPress, I’m linking to the SQL script here.