Password complexity gets complicated with AD Trusts

I came across an issue recently in a customer's SharePoint 2010 farm.  We were performing our annual service account password changes and ran into an issue.  The people picker in our DMZ stopped working and the service account that handles that authentication kept getting locked out.  Unless the account was already cached in the user information list, new user accounts could not be queried and the address book feature was broken as well.

Because we have a AD trust set up, we have to run the following command to restore the credentials:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:web.net,domain1\svcacct1,password; forest:web.dmz,domain2\svcacct2,password" -url http://yourwebsite 

Even after running this, the people picker still did not work.  It got me thinking about the complexity of the password.  We actually had semi-colons and commas in the password for one of these service accounts, so when the command was run, it was picking up these special characters as part of the command, instead of part of the password.

After changing the password to remove these special characters, I was able to re-run the command and the password took successfully.  We then unlocked the accounts, performed an IISRESET, and BAM! the people picker again started working.

So keep in mind when choosing the complexity of your passwords.  We want to be secure, but there are some instances where special characters should be avoided.  My preference is to not use the following characters for service account passwords, particularly if you like to use powershell cmdlets:

$ - can be mistaken for a variable
; - is often used in a string to separate sections
, - same as above
Lastly, I try to avoid capital Os because they can get mistaken for a zero.

Hopefully this helps.

SharePoint Wiki Library View Issue

A coworker encountered something very strange a few days ago, and I thought it warranted a blog post.  He was migrating documents from a SharePoint 2010 document library into a SharePoint 2013 library.  He noticed that after he moved the files, when he would click on the link to the new library, the default view would actually show up as a wiki page, instead of simply listing the contents of library.  He tied changing the default view and playing around with the library settings, but nothing helped.

When I took a look at it, I noticed that there was a document that was moved to the library called "home.html".  That's when it clicked.

In SharePoint 2013, if you are using a wiki page library and there is a page in the library called "home" or "default", the wiki will default to opening this page from all site contents, instead of the all pages list view.

This would also apply to the Site Pages library.  If you have a page stored with the name "default", it will automatically pull this page up instead of the library. Simply rename this file to something else, and the link to the site pages will work correctly again.