SharePoint 2013 Service Pack 1 has been released. Note that while Service Pack 1 does support Windows Server 2012 R2, Windows Server 2012 R2 support requires a new SharePoint 2013 with Service Pack 1 ISO to be released. Slipstreaming or installing RTM and then SP1 on Server 2012 R2 is not supported. Foundation: http://support.microsoft.com/kb/2817439 Server: http://support.microsoft.com/kb/2817429 Project Server: http://support.microsoft.com/kb/2817434 Foundation Language Pack: http://support.microsoft.com/kb/2817442 Server Language Pack: http://support.microsoft.com/kb/2817438 Office Web Apps: http://support.microsoft.com/kb/2817431 Office 2013 Client: http://support.microsoft.com/kb/2817430 List of Server Updates: http://support.microsoft.com/kb/2850035 List of Client Updates: http://support.microsoft.com/kb/2850036

The post SharePoint 2013 Service Pack 1 Released appeared first on Nauplius.

Service Packs typically contain little-to-no features. SharePoint 2013 SP1 is no different, however there are a couple of things I wanted to point out. First, both Yammer and OneDrive are apparently a critical SharePoint Central Administrator error: You can now configure Yammer and OneDrive for Business on Office 365 with SharePoint On-Premises integration. This can be done via Central Administration:   OneDrive now replaces SkyDrive in the top link bar. Included with this is Yammer, if you activate the Yammer feature on-premesis via Central Administration.   When you click on the Yammer link, you’ll be directed to /_layouts/15/Yammer.aspx and be asked to log in. That’s about it…   Once Yammer is activated, the SharePoint “newsfeed” will now display this message when you visit your MySite. For OneDrive for Business on Office 365 integration, again in Central Administration -> Office 365 -> Configure OneDrive and Sites Link, you’ll simply input your OneDrive host in Office 365 (https://<tenant>-my.sharepoint.com) and the top link bar will redirect you there when you click on OneDrive.   That is it for ‘on the surface’ new features! Another note I wanted to point out is use Russ Max’s installation script. It will save you hours of deployment on Service Pack 1. In addition, a reboot will not necessarily be required.

The post SharePoint 2013 and Office 365 with Yammer Integration appeared first on Nauplius.

With the release of SharePoint 2013 Service Pack 1, you can now re-calculate site storage metrics on demand. This is done via PowerShell. [crayon-531273e73b7f2450488786/] This method executes proc_RecalculateStorageMetricsForSite, which can be found in each Content Database. The Content Database must be at the SP1 schema level. Storage metrics can be found on each site by visiting http://siteUrl/_layouts/15/storman.aspx.

The post Re-calculate Site Storage Metrics On Demand appeared first on Nauplius.

If the SharePoint Configuration Cache folder, along with the cache.ini file go missing, you’ll likely notice the SharePoint Timer Service failing and restarting over and over again, along with a lack of scheduled timer jobs. The Timer Service failures will look like this in the System Event Log. [crayon-531273e738cb8218277674/] Given this is the case, how do you restore the folder and cache.ini? The folder is a GUID, and unique to the farm, so creating just any folder isn’t going to work. The best method to recover the folder and file when no backups are available (and why would you backup a folder filled with transient  files?) is to take a backup of your Configuration database and restore it under a new name (this is done for supportability reasons, SharePoint databases should be treated like black boxes). Then, query the Configuration database using the following command: [crayon-531273e738cd2629581894/] The returned value is the name of the folder that should reside in C:\ProgramData\Microsoft\SharePoint\Config\. Create this folder and create a new cache.ini. Within cache.ini, add “1″ (without quotes) and save the file. Start the timer service (or as it is probably continuously crashing, it will start itself), and that should resolve the timer service crashes. Note that if the farm has multiple SharePoint Servers, follow the standard advice on other SharePoint servers that are working — stop the SharePoint Timer service, and flush the cache, then after resolving the issue with the problematic SharePoint server, start the Timer service on all SharePoint servers. Once the folder and cache.ini are recreated, and the Timer Service back up and running, the folder will be populated with XML files, the timer service will stop crashing, and finally timer jobs will start showing up as scheduled and running.

The post When the Configuration Cache Folder Goes Missing… appeared first on Nauplius.

Microsoft has released the SharePoint 2013 with Service Pack 1 ISOs (including Project Server  and Office Web Apps). These ISOs are required for Windows Server 2012 R2 support as it includes an updated prerequisite installer, which does not ship with the normal Service Pack binary. The new ISOs are available via MSDN Subscriptions and while I do not have access, likely the Volume License center as well.

The post SharePoint 2013 with Service Pack 1 ISOs Released appeared first on Nauplius.

You may have a SharePoint installation where the servers have no Internet access. In this case, it is typically required that you run the prereqinstaller.exe with switches pointing to the binaries. But what if you didn’t know where to get the binaries, such as WCF Data Services 5.6 now required by the SharePoint 2013 with Service Pack 1 installer? Simple! Use one of two programs: Strings or Process Explorer. Both of these processes can be done on any 64bit Windows computer. With Strings, simply mount the ISO or extract the contents to disk and run strings using the -u switch (Unicode) against the executable: [crayon-533b7cc6ec765137742595/] The result is: Alternatively, execute the prerequisiteinstaller.exe. On an unsupported Operating System (e.g., Windows 8) it will report that the tool does not support the current operating system. That’s OK, just leave it running. Next, run Process Explorer “As Administrator” and find prerequisiteinstaller.exe in the Process list. Right click and go to Properties (or double-click), then select the Strings tab. Make sure the Image button is selected, and search for “http://go”. All of the download links are grouped into this single section of the image. Alternatively, you can save the strings to text and search the text file. Now you now how to find all of the pre-requisite download URLs!

The post SharePoint Prerequisite Installer Download Links appeared first on Nauplius.

The Name property in the User Profile Service Application (also known as PreferredName) controls how a user’s friendly name will appear within the UPA (and by extension, SharePoint). By default, this property is mapped to a Synchronization Connection’s displayName attribute. Changing the Name property from the displayName attribute to another attribute will cause the Name property’s mapping to disappear on a restart of the User Profile Synchronization Service (for example, during reprovisioning after a full farm backup has taken place). If the SharePoint administrator then attempts to change the Name property mapping back to the displayName attribute, the mapping will also disappear during reprovisioning. The reasoning for this happening is that by default, SharePoint creates the Name property with the following flow using the displayName attribute: When changing the Name property to a new attribute, the flow is changed like so (in this particular case, the displayName attribute mapping was remove, and re-added, returning back to Manage User Properties in between each edit): Note the metaverse attribute is now PreferredName. Because this is a Direct mapping, it no longer correlates to the Name property in use by the UPA. Any changes to the Name property moving forward will change this new Direct mapping, rather than the proper Extension mapping. As a result, the Name property will appear to have no mapping: To resolve this issue, delete and recreate the Synchronization Connection. The default mapping will be restored and will not disappear on UPSS reprovisioning. As a result, I’d recommend not adjusting the mapping of this property. This issue was validated in SharePoint 2013 SP1.

The post Name User Profile Property Mapping Blank After Reprovisioning appeared first on Nauplius.

The April 2014 Cumulative Update for SharePoint 2013 has been released. SharePoint Foundation: Not released yet SharePoint Server 2013: Not released yet Project Server 2013: http://support.microsoft.com/kb/2863881 Office Web Apps Server 2013: http://support.microsoft.com/kb/2863899 Office 2013 April 2014 Cumulative Updates: http://support.microsoft.com/kb/2953733

The post SharePoint 2013 April 2014 Cumulative Updates appeared first on Nauplius.

As many have noted, SharePoint 2013 Service Pack 1 downloads were pulled. This is due to a potential issue with upgrading from Service Pack 1 to any future update. This does not impact day-to-day operations and should not be a cause of concern for those currently running a farm upgraded to Service Pack 1. Microsoft will release a fix to address this particular issue so administrators may update to post-Service Pack 1. The ISOs that include Service Pack 1 (“SharePoint 2013 with Service Pack 1″) are not impacted by this particular issue. Those ISOs can be found on the MSDN Download Center and the Volume License website. Now as for Hearbleed, because Microsoft does not use the OpenSSL crypto library, Microsoft products and properties (with the exception of Yammer) will not be vulnerable to this particular issue. This, by nature, extends to SharePoint. However, if the same SSL certificate was used with an IIS site as well as a site using the vulnerable OpenSSL crypto library, the certificate will still need to be revoked and reissued, and of course any user associated with the site should change their password(s). Unfortunately this particular bug is very bad for users. They cannot know if a web server is vulnerable, and cannot know if and when the vulnerability is resolved. As always, it is best to regularly rotate passwords and use unique passwords on a site-by-site basis. I’d suggest using an application like LastPass, so you don’t necessarily have to “remember” each password. Patch Tuesday has passed, and as you may have noted, Patch Tuesday typically means Cumulative Updates for SharePoint. We’re still waiting for the SharePoint 2013 CUs to be released. Hopefully the SP1 update issue will also be addressed with this release. On another note, when the April 2014 CU is released for SharePoint 2013, we’ll have official support for SQL Server 2014 RTM! The blocking issue was due to Forefront Identity Manager (when is FIM not the blocking issue?).

The post SharePoint 2013 SP1 and Heartbleed appeared first on Nauplius.

SharePoint 2013 SP1 has been re-released with updated binaries that support future updates. The links to the ‘v2′ SP1 can be found in the previous SP1 post, SharePoint 2013 Service Pack 1. This new SP1 can be installed over-the-top of a previous SP1 deployment. Don’t forget to run the Config Wizard after installation.

The post SharePoint 2013 Service Pack 1 Re-Released appeared first on Nauplius.

SharePointBAC is a set of PowerShell cmdlets for managing and reporting on SharePoint Farm backups, created by Sean McDonough. This update provides a fix for reporting when the Start and/or Finish time is not available. SharePointBAC is a farm solution available for SharePoint 2010 and SharePoint 2013. Download this release from the SharePointBAC project page. Also check out my other solutions in my portfolio!

The post SharePointBAC 1.1.1 Release appeared first on Nauplius.

The SharePoint 2013 April 2014 Cumulative Update includes three new SQL Availability Group cmdlets: Get-AvailabilityGroupStatus Add-DatabaseToAvailabilityGroup Remove-DatabaseFromAvailabilityGroup These cmdlets allow you to manage the SQL Availability Group. First, a few notes about the Availability Group. The AG must be the connection in use by the Configuration database as checks for the Database Availability group will be executed against this connection. If the Database Availability group happens to be on another set of SQL Servers that is not the Configuration database SQL server connection, those checks will fail. The Availability Group must have a Database Availability Group Listener. Again, without it, the checks will fail. To confirm that the check will succeed, modify the AGName parameter in this T-SQL query and run it against the SQL instance used by the Configuration database: [crayon-5374890d5b5ee388054015/] Let’s start with a brand new farm. Two SQL Servers, SQLAO1 (Primary), and SQLAO2 (Secondary) in a SQL Availability Group (Synchronous mode) named SPAG (DNS name is SPAG.nauplius.local). A dummy test database has been created in order to set up the AG, but may be deleted. The SharePoint server is SharePoint 2013 SP1 with April 2014 CU. No SQL Alias will be used for this set up since we have database mobility between SQL Servers due to AlwaysOn. Starting with an elevated SharePoint Management Shell… [crayon-5374890d5b646072305250/] Because SQLAO1 is the Primary Replica, the Administration and Configuration databases are present on it, but not SQLAO2. The next step is where the AlwaysOn fun begins. Validate a good backup location is available for each SQL Server (note that your SQL Server service account(s) will need access to this location). Run the following command from the SharePoint Management Shell: [crayon-5374890d5b664721739385/] And that is it! Your Configuration and Administration databases are now part of the SQL Availability Group (in a real sense), there was no having to flip-flop SQL Aliases around, the databases are automatically backed up and synchronized, as are the SQL Logins! This also eliminates the need for a Database Administrator to assist with getting SharePoint databases into an Availability Group, because it can now be done by the SharePoint Administrator! You can also now see the status of the Availability Group: [crayon-5374890d5b67d422195473/] If you run Add-DatabaseToAvailabilityGroup, but the cmdlet errors out, an Availability Group object may be created within SharePoint regardless. To fix this, simply run: [crayon-5374890d5b696940652795/] For databases that are part of the SharePoint SPAvailabilityGroup (rather than simply being in an AG as done from SQL Management Studio) will also be aware of that through their object. [crayon-5374890d5b6ad963451595/] On the SharePoint SPAvailabilityGroup object itself, we can also force a failover to one of other nodes in the Availability Group: [crayon-5374890d5b6c6251575297/] Yep, as a SharePoint Administrator, I do not have to touch SSMS or SQL PowerShell to execute an AG failover anymore! If, down the road, you create a new database (Content or Service Application) and need to individually add it to a new or existing Availability Group, again use the Add-DatabaseToAvailabilityGroup cmdlet. Pay attention to what the Primary replica is, as the last backup path will be used if the FileShare switch is not specified. So for my above example where my FileShare path is on SQLAO1, but I’ve failed over to SQLAO2, if I attempt to use the Add cmdlet, the backup will fail with Access Denied. Instead, I created a new share on SQLAO2 and ran: [crayon-5374890d5b6de149594136/] Of course, you could use a common CIFS location that the SQL Server service accounts had NTFS Modify access to, as well. The last cmdlet, Remove-DatabaseFromAvailabilityGroup, will remove databases from the SharePoint SPAvailabilityGroup object. If you attempt to run the cmdlet against a database that currently exists within SharePoint (for example, is still attached to a Web Application), the cmdlet will fail with an error similar to: [crayon-5374890d5b6f6350509467/] This is a little bit misleading (and there is a slightly better error in the ULS logs). If you use the -Force parameter, what it does is it removes it from the Availability Group, deleting the database from the Secondary nodes of the SQL Availability Group (by default), but the database will still be attached to SharePoint. If you need to remove a database from an Availability Group, but wish to keep copies of the database on the Secondary nodes, use the -KeepSecondaryData parameter. The database, on the Secondary nodes, will enter a Not Synchronizing state, while the database with the active connection will no longer display a synchronizing state as it is no longer part of the Availability Group. One potential bug to note is that it appears the Secondary replicas do not have the Max Degree of Parallelism (MAXDOP) set to 1 at any point by SharePoint. Make sure to set it manually prior to deploying SharePoint databases as this can cause certain operations to fail, such as creating new Content Databases.

The post SharePoint Database Availability Group Cmdlets appeared first on Nauplius.

SharePoint 2010 2013 relies on an old default: SSL 3.0 and TLS 1.0 for secure communication. While you can disable SSL 3.0 on SharePoint servers, you cannot disable TLS 1.0. A .NET hotfix was add support for TLS 1.1 and TLS 1.2 in the .NET 4.5 Framework, but this requires rebuilding the application that relies on the .NET framework in order to use the new protocols — not something that will happen with SharePoint 2013. Current versions of SQL Server also have the same limitation when using encrypted connections (which you should be). So, disable SSL 3.0 on your SharePoint servers, but leave TLS 1.0 enabled. I created a Group Policy ADMX file to help with this in mass-deployments.

The post SharePoint Support for Disabling SSL 3.0 and TLS 1.0 appeared first on Nauplius.

The SharePoint 2013 August 2015 Cumulative Updates have been released: SharePoint Foundation: https://support.microsoft.com/en-us/kb/3055004 SharePoint Server 2013:   https://support.microsoft.com/en-us/kb/3055009 Project Server 2013: https://support.microsoft.com/en-us/kb/3055005 Office Web Apps 2013: https://support.microsoft.com/en-us/kb/3055003 Office Updates: https://support2.microsoft.com/kb/3083805

The post SharePoint 2013 August 2015 Cumulative Updates appeared first on Nauplius.

Update October 2015: This issue is resolved in security update KB3085582, SharePoint Foundation, SharePoint Server, and Project Server 2013 Cumulative Updates. Update to one of these patches rather than using the below method. As noticed on a TechNet forum post, the August 2015 CU for SharePoint 2013 has a new regression with attaching files to List Items. This can be reproduced with a Custom List (possibly others) by creating a new List Item, clicking “Attach File”, identify any file that contains characters not listed in KB905231, then click OK. The error message “File names can’t contain the following characters” will appear:   A temporary workaround is available for this issue, but involves editing files in the 15 hive. Prior to performing this, make backup copies of these files. These backups must be in place prior to installing the next SharePoint patch. There are two JavaScript files that must be edited: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\FORM.debug.js C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\FORM.JS For , change the text starting on line 5307 from: To: And for , find the following string: Change it to: Once completed, clear the browsers cache and re-test. If the error still exists, try using Inprivate browsing mode, which will not use the cache from the regular session. A second workaround is also available, this does not involve any file editing. In a List, create a List Item and save it without attempting to attach a file. On the List, highlight the specific List Item that was created. In the ribbon, click on Items -> Attach File. This dialog will allow you to successfully attach a file to a List Item. A PSS case has been opened for this issue and the above solutions are the current official workarounds.

The post August 2015 CU Error – “File names can’t contain the following characters” appeared first on Nauplius.

The SharePoint 2013 September 2015 Cumulative Updates have been released: SharePoint Foundation: https://support.microsoft.com/en-us/kb/2975894 SharePoint Server 2013: https://support.microsoft.com/en-us/kb/2986213 Project Server 2013: https://support.microsoft.com/en-us/kb/2986195 Office Web Apps 2013: https://support.microsoft.com/en-us/kb/3085487 Office Updates: https://support.microsoft.com/en-us/kb/3092181

The post SharePoint 2013 September 2015 Cumulative Updates appeared first on Nauplius.

The SharePoint 2013 October 2015 Cumulative Updates have been released: SharePoint Foundation: https://support.microsoft.com/en-us/kb/3085488 SharePoint Server 2013: https://support.microsoft.com/en-us/kb/3085492 Project Server 2013: https://support.microsoft.com/en-us/kb/3085489 Office Web Apps 2013: https://support.microsoft.com/en-us/kb/3085571 Office Updates: https://support.microsoft.com/en-us/kb/3099951 Consider using the SharePoint Patch Cmdlets available at SharePoint Updates for your farm!

The post SharePoint 2013 October 2015 Cumulative Updates appeared first on Nauplius.

The SharePoint 2013 November 2015 Cumulative Updates have been released: SharePoint Foundation: https://support.microsoft.com/en-us/kb/3101368 SharePoint Server 2013: https://support.microsoft.com/en-us/kb/3101373 Project Server 2013: https://support.microsoft.com/en-us/kb/3101369 Office Web Apps 2013: https://support.microsoft.com/en-us/kb/3101367 Consider using the SharePoint Patch Cmdlets available at SharePoint Updates for your farm!

The post SharePoint 2013 November 2015 Cumulative Updates appeared first on Nauplius.

The SharePoint 2013 December 2015 Cumulative Updates have been released: SharePoint Foundation: https://support.microsoft.com/en-us/kb/3114339 SharePoint Server 2013: https://support.microsoft.com/en-us/kb/3114345 Project Server 2013: https://support.microsoft.com/en-us/kb/3114341 Office Updates: https://support.microsoft.com/en-us/kb/3121650 Consider using the SharePoint Patch Cmdlets available at SharePoint Updates for your farm!

The post SharePoint 2013 December 2015 Cumulative Updates appeared first on Nauplius.

SharePoint Libraries include a search box for that specific library, e.g.: Prior to the August 2015 Cumulative Update, it was possible to find an item within the specific folder of a library. In the above example, if you went into Subfolder and then searched for an item, the search would be limited to items within that subfolder. After the August 2015 CU has been applied, the search box is no longer context sensitive. All items will be returned from the library that match the specific search term. This is due to a change in the file INPLVIEW.js (and INPLVIEW.debug.js) where a function call was dropped which prevents the context sensitive search from working. As a temporary workaround, it is possible to modify these files to get this search functionality to it’s original state. The first thing that needs to be done is to make copies of INPLVIEW.js and INPLVIEW.debug.js, which are located in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\. These copies must be restored prior to installing a SharePoint patch, otherwise the files may not be updated by a patch. Next, in INPLVIEW.debug.js, open the file with a text editor and go to line 3058. This line will be within the function named “HandleRefreshViewInternal”. Line 3058 should not have any text. Add the text: For INPLVIEW.js, find the text . Immediately after that text, add: For INPLVIEW.debug.js, the entire function will look like: And for INPLVIEW.js: There is a PSS case open for this issue to revert the change back to pre-August 2015 CU behavior.

The post Context Sensitive List Search Broken by August 2015 CU appeared first on Nauplius.