What this does is recurse through a directory structure looking for setup.exe files and then fires them off one at a time. You'll see that I also have an ArgumentList parameter I'm passing to Start-Process - this is the location for the config.xml for the silent install and suppresses the EULA so you should be able fire off the script and walk away.

Here's what you want to do...

• First, you want to make a directory structure somewhere on your machine like this:
• d:\LanguagePacks
• d:\LanguagePacks\French
• d:\LanguagePacks\German
• d:\LanguagePakcs\Spanish
• etc...
• Second, download each language pack to your SharePoint machine into the respective folder.
• When I did this, they downloaded as a .IMG file, so I had to mount the IMG and pull the files out manually. I'm sure I could have scripted this part too, but I'm lazy and it's a one time deal for me.
• Edit the script and point to the root folder that holds all the language folders, then you can run it.

Get-ChildItem -path "d:\LanguagePacks" -recurse | ?{$_.Name -eq "setup.exe"} |%{Write-Host "Installing at" $_.FullName; Start-Process -filepath $_.FullName -ArgumentList "/config .\files\setupsilent\config.xml" -wait}

Remember - you have to run PSConfig on all the machines you have the Language Packs installed, so be sure to run that after the powershell finishes:

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

http://support.microsoft.com/kb/2765260

So why am I posting this? Well, the steps in the KB are correct but depending on your situation, you may need a bit more information still.

When I ran the second powershell command to install all the features, it kept getting hung at 68% and the error was that it couldn't download the required files. I needed to specify a -source path to the command.

To my confusion, what path should I be telling it? I already had the DVD of Server 2012 in the drive...well, here's what I figured out.

The source path needs to be to the .\source\sxs directory of the install media for the OS.

Once I specified that location, install completed successfully for all the IIS components - so now I wait for the reboot and try the prerequisite installer once more.

Happy SharePointing. :)

SP2010 Link:

http://support.microsoft.com/kb/2658222

SP2007 Link:

http://support.microsoft.com/kb/2658224

Happy patching!

Edit: Here are the roll up packages

Description of the SharePoint Server 2010 cumulative
update package (SharePoint server-package): March 7, 2012

http://support.microsoft.com/kb/2597150

Description of the SharePoint Foundation 2010 cumulative
update package (SharePoint Foundation server-package): March 7, 2012

http://support.microsoft.com/kb/2597132

Some of you may look at Task Manager to see what’s going on at a high level. You notice there’s not much going on from the WFE’s memory and CPU utilization. Nothing looks abnormal. Next, you might hit the event logs to see if there’s any errors, and you’d come up empty. Now what? On to the diagnostic logs for SharePoint (ULS logs), but what might we look for? I’d always start my searches for “exception”, “fail”, “error” and in this case I’d come up empty (well, empty for chasing down this particular problem anyway). Hm, what’s next? Dumps maybe? Well, if you’re so inclined and know what you’re looking at, sure…go for it. What you’d likely find in this case is one thread per user request sitting and hanging out waiting for a response back from SQL.

Interestingly enough, SharePoint has a query timer built right in the product and it logs long running queries and the time taken right to the ULS logs, you just have to know what you’re looking for.

Enter the great 8sli. You might say you were just in the ULS logs and didn’t find anything. Well, that’s because you, like me at the time, probably didn’t know what it was you were looking for. Here’s an example of what this particular entry would look like:

09/06/2011 12:59:21.04 w3wp.exe (0x1B74) 0x23F4 Windows SharePoint Services Database 8sli Monitorable List item query elapsed time: 35547 milliseconds, Additional data (if available): Query HRESULT: 0 List internal name, flags, and URL: {44B9C682-4C16-4731-9861-7681793B4BEC}, flags=0x0000000004801008, URL="REMOVED" Query XML: "<Query><Where><Eq><FieldRef Name="ID"/><Value Type="Integer">15</Value></Eq></Where></Query>" SQL Query: " SELECT t2.[tp_Created] AS c3c8,t1.[Type] AS c0,t3.[tp_ID] AS c10c5,t1.[Id] AS c15,t4.[tp_Created] AS c17c8,UserData.[tp_ItemOrder],UserData.[tp_ModerationStatus],UserData.[nvarchar1],UserData.[nvarchar6],UserData.[tp_Created],t1.[CheckinComment] AS c23,UserData.[tp_WorkflowInstanceID],t2.[nvarchar4] AS c3c6,t3.[tp_Created] AS c10c8

As you can see from the above, the reason we didn’t find it in the first place when we were in the ULS logs was that we weren’t looking for “monitorable” because that would have yielded us far too many results to sift through. In this case, though, it would have been lucrative to do so given we were chasing a reason why a page might take so long to render.

This entry in and of itself does not provide us a smoking gun, but the URL (which I removed) would have contained a pointer to where the query originated which is a huge step in the right direction. Once you have the URL nailed, you can then fire up a SQL profiler trace when you hit that URL and you would find some parameter data that would help you figure out why the query was taking so long. You’d also have things like the ListID, SiteID and other valuable things to help you on your hunt.

Pro Tip #489: Use ULSViewer, it makes short work of filtering ULS logs by these tags. It can be downloaded here: Ulsviewer

Thanks to my buddy Alonzo Milow for pointing this out to me. He’s a MS PFE on my team, but I don’t think he blogs yet. I’ll work on that.

Happy hunting the great 8sli.

I had an interesting little challenge crop up the other day that required me to need to change a custom user profile property inside of SharePoint’s 2010 User Profile Service Application. I have thousands of profiles and certainly didn’t want to get comfy with the mouse and keyboard all day, so I decided to whip up a little script to do the dirty work for me.  Hopefully someone will find this useful as I couldn’t find it already put together.

#Add-PSSnapin Microsoft.Sharepoint.Powershell
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint") | out-null
[reflection.assembly]::LoadWithPartialName("Microsoft.Office.Server") | out-null
[reflection.assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles") | out-null

$site = "http://sp2010dev"
$property = "Title"
$value = "TestValue123"

$spsite = Get-SPSite $site
$context = Get-SPServiceContext $site
$upm = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$enum = $upm.GetEnumerator()

while ($enum.MoveNext())
{
    [Microsoft.Office.Server.UserProfiles.UserProfile] $user = $enum.Current
    Write-Host "Working on profile for: " $user.DisplayName
    Write-Host "Old Value: " $($user[$property])
    $user[$property].value = $value
    $user.Commit()
    Write-Host "New Value: " $($user[$property])
}

Ever needed to use a sharepoint query to drive data through another script or other code?

Well, here's your answer. :)

I whipped this little widget up to use the KeywordQuery class to issue queries to a site and saves off the results as a CSV file.

Things to remember: Use the Microsoft.Office.Server.Search.Query.KeywordQuery class to do your dirty work, not Microsoft.SharePoint.Search.Query.KeywordQuery unless (I believe) you are using WSS 3.0 or SharePoint Foundation Server 2010 only.

And here you go - just save that off as .ps1 and run it from your SharePoint Management Console window

#input parameters 
param($site, $queryText, $outputPath) 
 
 
# new keywordquery object 
$site = New-Object Microsoft.SharePoint.SPSite $site 
$query = New-Object Microsoft.office.Server.Search.Query.KeywordQuery $site 
 
# set ResultTypes 
$query.ResultTypes = [Microsoft.Office.Server.Search.Query.ResultType]::RelevantResults 
 
# set number of items to return 
$query.RowLimit = 10 
 
# actual string you are searching for 
$query.QueryText = $queryText 
 
# execute the query 
$resultTableColl = $query.Execute() 
 
# get the results back 
$resultTable = $resultTableColl.Item([Microsoft.Office.Server.Search.Query.ResultType]::RelevantResults) 
 
# make a DataTable from the results 
$resDataTable = $resultTable.Table 
 
# output the results, select the properties you want back, export to CSV file 
$resDataTable.Rows | Select-Object -Property Path,Title | Export-Csv -Path $outputPath 
 

Well, Todd Carter (from my team) has decided to keep this information in one spot and published the information here.

Hope it helps someone!

http://www.todd-carter.com/page/SharePointVersions.aspx

 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a06a0fea-a4d4-434e-a527-d6afa2e552dd

Default is a grouping that you can control what's in it by going into Central Admin | Application Management | Configure Service Application Associations and clicking the default Application Proxy Group. This will bring a dialog that allows you to select from the provisioned service applications and make your default group. Custom is the other one you get out of the box. Custom, however, is just a one-off custom selection of the provisioned service applications. It's not like applying a pre determined group setting, it's an ad-hoc choice of the provisioned applications.

This is fine and all if you just want a one-off set of assignments. But what if you wanted to have a couple of pre-canned groupings to select from in a repeatable manner? Enter, powershell.

Using powershell, you can create a custom proxy group and assign service application proxies into the group to be available as a drop down selection on your web applications in Central Admin. Interestingly enough, once you assign one of your web applications to use your new custom proxy group, you now have a link in Central Admin that is directly to your proxy group that gives you a nice UI to pick and choose what is associated with your custom proxy group. So, creating the group and adding at least one group member is just a one time activity per group you create. Once it's created and associated with a web application, it's back to the UI for you...unless you just really like powershell.

Below is the required powershell to create a custom proxy group and add a service application proxy to that group.

#Create new proxy group

$newProxyGroup = Add-SPServiceApplicationProxyGroup -name "My Custom Proxy Group"



#Get reference to the proxy of the service application

$metaDataProxy = Get-SPServiceApplicationProxy | Where{$_.DisplayName.StartsWith("MetaData")}



#Add proxy member to new proxy group

Add-SPServiceApplicationProxyMember -identity $newProxyGroup -member $metaDataProxy

Anyway...that's it for now. I'm sure it won't be too long before the information starts to roll in.

Stay tuned...