PowerShell support for SharePoint Add-ins is very minimal. A limitation I ran into today is that you can use PowerShell to register an App Principal, or to retrieve one, but deleting the principal is not possible.
On W10 it is trivially easy to retrieve stored passwords for wireless netwerk. I cobled the following script together to store the passwords before a migration. Note that this assumes an English version of Windows, on some machines you may need to modify the ‘User Profiles’ and ‘Key Content’ strings.
Just documenting two methods that work, since I’m tired of googling this every few months:
Internet Explorer on Windows Server (2012) is locked down. In an attempt to make the browser more secure, scripts downloaded from untrusted domains can not be executed. This makes downloading the software you need to install on the server difficult.
SharePoint Add-ins * are distributed through the App Catalog. This is a great method for end users to add functionality to their sites. Most apps you want to have available to as many users as possible, everybody should be able to add the local weather app, or the handy currency calculator to their sites.
The SharePoint app* infrastructure is a notably fickle beast. I’ve seen grown system administrators reduced to tears by obtuse error messages and exotic requirements which don’t fit company infrastructure policies (wildcard certificates, no support for SSL offloading, multiple IP’s or NICs etc etc.).
SharePoint folders have had it rough the last couple of years. The internet is full of ‘folders are evil’ posts, but in my view folders still have their uses. One of the interesting features SharePoint folders bring to the table is automatically setting metadata. Per folder you can configure which default values fields should have. This can be a great enabler when people don’t want to tag documents manually.
The SharePoint product team faces a daunting task in keeping the MSDN library on SharePoint API’s up to date. Especially now we have the Server Side Object Model, Client Side Object Model and the JavaScript Object Model. Although the documentation for these API’s may be sparse at points, it at least tries to cover the entire object model, which is a good thing. Next to that there is also the REST API, which is so badly documented that complex solutions become nearly impossible.
There are lots of posts out there dealing with the various troubles you can run into when trying to get your sandboxed solutions to work as they should. Most focus on getting the User Code Host to start and they do a pretty good job explaining that. However, there is one scenario that doesn’t appear to get as much attention as it should; what happens when you don’t use the farm account for the sandbox service. By default, SharePoint uses the farm account for the User Code Service. However, Microsoft advises us wisely to use separate accounts for separate services. This allow for a better management of privileges. Never is this requirement more clear then when you are configuring a sandbox. Using the farm account, which has a lot of privileges, partially defeats the purpose of having sandbox has in the first place. So, we see more and more production servers with separate accounts for the user code service, which is a good thing. However, developers are also exposed to this and get errors they don’t understand: When deploying by hand you might see the following in the ULS:
The SPWeb object is one of the places where a lot of the SharePoint magic happens. Many changes performed through the UI or through features are persisted there. When refactoring behavior it’s often useful to compare the state of the SPWeb object before and after an update. I’ve created a small powershell scrip to facilitate this. It reads all the properties of the SPWeb and all the properties in the property bag. It then pauses, allowing you to do whatever you have to. Then the script gets the properties again and outputs the differences. Let me know if it helps you.
It’s been a while since I last posted here. Almost 2,5 years have passed since my last post. I’ve still been doing SharePoint, I just never got around to blogging about it. I’ll try to post more in the coming months, so check back for updates.
SharePoint 2010 saw the introduction of ‘Document Sets’. In my opinion these are the greatest improvement in document management since the stapler. The concept is very simple; you create sets of documents. These sets have their own introduction page, where you can leave relevant info. Also, the documents in the set can share metadata properties and the set itself can have distinct properties which may or may not get pushed down to the documents in the set.
