Wednesday, December 21, 2016

Windows Server 2012: To sign in remotely, you need the right to sign in through...


Problem

You obtain a new Windows Server 2012 R2 VM from your system admins. You develop on this, and then provide other users the name or IP address of your VM so that they can view your development efforts. You add their AD accounts to the server's local Remote Desktop Users group. They report that they are unable to connect, seeing this message:

Solution

Check the Allow log on through remote desktop services user right:
Start > Administrator Tools > Local Security Policy > Local Policies > User Rights Assignment
or
mmc > Result Set of Policy > expand tree > Windows Settings > Security Settings > Local Policies > User Rights Assignment
If the security setting for this policy only includes the local Administrators group, add your users to this group.

Notes

  • By default, the security setting for this policy should include the local Administrators and Remote Desktop Usersgroups. However, your system admins may have configured the domain's GPO to not include the Remote Desktop Users group.
  • Though adding users to the local Administrators group does get them remote access, it provisions your users with a higher level of server access than you may want to grant. The long term and best solution is to request system admins to modify the domain GPO to include the Remote Desktop Users group in the security setting for the Allow log on through remote desktop services user right.
  • Using the RSoP snap-in will help you see what GPO is applied.

References

Monday, December 5, 2016

SharePoint 2013: How to change all service account passwords


Introduction

This posting collates all of the various different procedures associated with changing SharePoint 2013 service account passwords.  Changing passwords is a common task on the departure of a SharePoint admin.  This posting documents this critical task.  This posting assumes that neither the farm service nor any other SharePoint service account (including the UPS profile service account), has been provisioned with AD write access.  The SharePoint service accounts that will be engaged here typically include:
  • SPADMIN - SharePoint Setup User Administrator account.  not really a service account but included anyway as part of the Sharepoint account pantheon.
  • SPFARM - this is the server farm and database access account; also used for example by, User profile Synchronization Service, Security Token Service Application and AppPool
  • SPSEARCH - Search service application identity, for example, Search Host Controller Service, SharePoint Server Search, Search Service AppPool, Search Admin Web Service.
  • SPCONTENT - used by the Search service application as the crawling account.
  • SPAPP - used as the application pool identity for those application pools used by the content web applications and the My Site web application.
  • SPSERVICE - general service application identity account, for example, C2WTS, Distributed Cache, Sandbox Code Service, SharePoint Hosted Services and application pools (eg, App Mgmt, BDC, Excel Calc, MMS, Secure Store, UPSA, Visio, Word Auto, etc).
  • SPSQL - typically used to run the SQL Server service and the SQL Server Agent service.
  • SPSUPERR - used by object caching service to impersonate standard viewer.
  • SPSUPERU - used by object caching service to impersonate standard full control.
  • SPWORKFL - TBD
  • SPPROFILE - used by UPS to interrogate Active Directory and download user profile information from AD.

Procedure

  1. SPADMIN: Change SharePoint Setup User Administrator Account Password
    1. Description
      1. Standard domain account.
      2. This account is specially provisioned and used during initial deployment, and it is the account that should be used for all configuration tasks, such as executing PSCONFIG after installing a cumulative update.  It is also the account that has been configured with special privileges to launch the SharePoint Management Shell and run SharePoint-related PowerShell scripts. This account is not used in any service capacity. Therefore, its password can be changed straightforwardly like one would any other user account.
      3. I use this account also when installing cumulative SharePoint patches.  I have been informed by Stefan Gossner that it isn't necessary to use this account when installing patches and that any domain account having local admin privileges will do.  However, this is my policy and it has served me well over numerous patching sessions over many years.
    2. Type
      1. Unmanaged
    3. Password Change Procedure
      1. The procedure for changing the password for this user account is that same as changing the password for any other AD user account: 1) Launch Active Directory Users and Computers, 2) Right-click on the account and choose Change Password, and 3) follow the prompts.
  2. SPFARM: Change SharePoint Server Farm Account Password
    1. Description
      1. Standard domain account.
      2. This account is used to configure and manage the server farm; it acts as the application pool identity for the SharePoint Central Administration web application and it is this service account under which the SharePoint Foundation Workflow Timer Service runs.  Generally, these services and service applications use this account by default:
        1. Farm Account
        2. Windows Service - User Profile Synchronization Service
        3. Service Application Pool - SecurityTokenServiceApplicationPool
        4. Service Application Pool - SharePoint Web Services Default
        5. Service Application Pool - SharePoint Web Services System
        Additionally, you will see these Windows Server services provisioned to use this account by default:
        1. Forefront Identity Manager Service
        2. Forefront Identity Manager Synchronization Service
        3. SharePoint Timer Service
        You will need to use PowerShell to change this SharePoint Managed Account password in SharePoint rather than through the Central Administration Managed Accounts interface. The reason being that you may not have access to this web interface once you change the farm server account password, which is the identity for the web application that hosts the Central Administration website.  The next section here walks you through this process.
    2. Type
      1. Partially Managed.
      2. Having this account in SharePoint Managed Accounts will simplify some changes that you need to make, but others will still need to be done manually.
    3. Password Change Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed.
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Launch an elevated SharePoint Management Shell.
      5. Execute the following:

        $username="DOMAIN\spFarm"
        $newpassword=ConvertTo-SecureString -String "password" -AsPlainText -Force
        Set-SPManagedAccount -Identity $username -ExistingPassword $newpassword -UseExistingPassword:$true

         
      6. This can take a minute or two to complete.  There's a lot to update here and these changes are intricate.
      7. Now, open the Windows Server Services control panel on the SharePoint Server machine you are currently logged into, and then sort by the Log On As column.
      8. Scroll down until you see the services having the server farm account (eg, spFarm).
      9. For each of these services: 1) verify that it is running; 2) if its Startup Type has been changed to Disabled, change it back to Auto; 3) if it is not running then start it; 4) if on trying to start it, it prompts you for logon information, enter the appropriate logon info, including the new password, and then start it.
      10. Having done this for this SharePoint Server, repeat steps 7 - 9 on each of the other SharePoint servers in the farm.
      11. Now, connect back to Central Administration (from any SharePoint server), and then navigate to CA > System Settings >  Services on Server.
      12. Start any service here that should be started but that stopped after you changed the password.   In particular, verify that the User Profile Synchronization Service is started (See Note 2, below).
    4. Summary
      1. Changing the SharePoint farm server account is the most operationally sensitive.  If this account is unable to authenticate, it will cause your farm to be nonoperational. 
      2. It's important to restart SharePoint servers after implementing this password change.  This commits the change.  If you don't, some services and service applications may function and others may not causing your farm to function in an indeterminate state.
      3. It can take some time for the password change to be recognized by SharePoint, depending on the refresh frequency of your domain controllers.
  3. SPSEARCH: Change the SharePoint Search Service Account Password
    1. Description
      1. Standard domain account.
      2. This account is used as the Search service application (SSA) identity. 
      3. If you have deployed your search service using this approach, it will be the identity for all of the usual SharePoint 2013 SSA components, except for the Crawl component, which is configured to use the SPCONTENT account.
      4. Changing the password for this service account is easier than for the farm server account.  You still need to change the password first in AD using the usual method.  However, in SharePoint, rather than having to use PowerShell, you can change the SSA service account using the Central Administration Managed Accounts interface.  The next section walks you through this process.
    2. Type
      1. Managed
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed.
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Launch Central Administration.
      5. Navigate to: CA > Security > General Security > Configure Managed Accounts.
      6. Look for the Search service account (eg, spSearch), and then click the edit icon next to it.
      7. In the Credential Management section, check Change password now.
      8. Next, also in this section, select Use existing password, and then enter the password.
      9. Scroll down, and then click OK.  The page will be busy for less than a minute.  Once it returns, move on to the next step.
      10. On the Windows Server you are currently logged into, open the Windows Server Services control panel.
      11. Sort on the Log On As column, and scroll down to find these two services: SharePoint Search Host Controller and SharePoint Server Search 15
      12. Verify that these both have status Running. If they are stopped, start them.
      13. Repeat the previous step for each of the other SharePoint servers.
      14. Now, while logged into any SharePoint server, launch Central Administration, and then navigate to Manage services on server.
      15. Scroll down to the bottom and look for these two SharePoint services: Search Host Controller Service and SharePoint Server Search.  
      16. Verify that these SharePoint services are started.  If they are not started, start them.
      17. Repeat the previous step for each of the other SharePoint servers in the farm.
      18. Lastly, in Central Administration, navigate to the Farm Search Administration page and then to the Search Service Administration page. 
      19. Review the Search Application Topology section: do you see all green checks there?  If so, you're done.  If not, wait awhile, and then refresh: it can take a minute or two for the new authentication information to propagate to all the components of the SSA and then for these components to update their health information back to the Search Service Admin page.
    4. Summary
      1. Changing the Search Service Application service account is fairly simple - particularly if you have deployed the SSA to use a single service account for all SSA components except the Crawl component.
      2. If your farm has deployed its SSA using separate service accounts for the different SSA components, then simply repeat the above steps for each of the other SSA service accounts.
  4. SPCONTENT: Change Search Service Application Content Access Account
    1. Description
      1. Standard domain account.
      2. This is the account used by the farm's SSA to actually crawl content.  
      3. You can see it configured by navigating to the Search Administration page.
    2. Type
      1. Unmanaged
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed.
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Launch Central Administration.
      5. Navigate to: CA > Farm Search Administration > Search Administration.
      6. In the System Status section of this page (top section usually), look for Default content access account.
      7. Look across to the right, and then click on the account shown there.
      8. Enter the password for this account, and then click OK.
      9. Launch an Incremental Crawl of any content source and wait for it to complete.
      10. Check the Search Crawl Log and verify that there are no entries there that include such descriptions as "Access Denied" or "Update password".
  5. SPAPP - Change the Application Service Account Password
    1. Description
      1. Standard domain account.
      2. This account is generally used as the content web application pool identity.
      3. May also be used as identity for the Work Management Service Application (WMSA).
    2. Type
      1. Managed (if used for content web applications and WMSA)
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed. 
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Test content web applications by trying to connect to them.  You should see HTML 503 Service Unavailable messages in the browser.
      5. Remote into a farm application server using the SharePoint Setup User Admin Account (eg, spAdmin).
      6. Launch Central Administration.
      7. Navigate to: CA > Security > General Security > Configure Managed Accounts.
      8. Look for the App service account, and then click the Edit icon next to the title.
      9. In the Credential Management section, check Change password now.
      10. Next, also in this section, select Use existing password, and then enter the password.
      11. Scroll down, and then click OK.  The page will be busy for less than a minute. Once it returns, move on to the next step.
      12. Remote into a WFE.
      13. Launch an elevated command shell.
      14. Execute IISRESET, and then wait for it to complete.
      15. Repeat steps 5-7 for each WFE in the farm.
      16. Try connecting to each of the content web applications of the farm.  You may get the usual "Sorry...".  This is expected and is due to time out behavior: the IISRESET initiates a complete recompile of each of the web applications on the WFEs.  Keep trying.
      17. Once you verify the content web applications are back up, try hitting your My Site and your OneDrive.  Here too you may experience errors presented in the browser. This is expected.  The My Site web application was also recompiled (if they are co-hosted with your content web applications).
    4. Summary
      1. The SharePoint App service account (spApp) is typically used with content web applications and the Work Management Service Application (this is created and configured automatically for you during normal install).
      2. Managing this web application AppPool identity via SharePoint Managed Accounts makes changing this particular password a snap.
      3. An IISRESET is absolutely necessary after restarting SharePoint servers and then changing the password in Managed Accounts.  if you don't do this, you'll experience 503 Service Unavailable errors.
  6. SPSQL - Change the SQL Server Service Password
    1. Description
      1. Standard domain account.
      2. Used as the identity for the SQL Server Service.
      3. It may also be used as the identity for the SQL Server Agent Service.
      4. For this procedure, the SQL Server Browser instance is assumed to be running under the NT AUTHORITY\LOCALSERVICE account.
    2. Type
      1. Unmanaged
    3. Procedure
      1. Shutdown all SharePoint farm servers
      2. Change the password in AD Users and Computers as you would normally.
      3. Restart SQL Server.
      4. Remote into the SQL Server instance using an account that is a member of the local admin group (eg, spAdmin).
      5. Launch SQL Server Configuration Manager (Local).
      6. In the left navigation panel, open SQL Server Configuration Manager (Local) > SQL Server Services.  Typically the second item below SQL Server Configuration Manager (Local).
      7. Right-click on the SQL Server instance (eg, spSQL), and then select Properties.
      8. Enter the new password in the Password and Confirm Password fields, and then click OK.
      9. At the prompt to restart the service, click Yes.
      10. Repeat for the SQL Server Agent service.
      11. Exit SQL Server Configuration Manager.
      12. Launch SQL Server Management Studio (SSMS) and connect to this SQL Server instance.
      13. In the left Object Explorer panel, verify that a green arrow icon is displayed over the SQL Server name.
      14. Exit SSMS.
      15. Start the rest of the farm servers.
    4. Summary
      1. The SharePoint SQL Server service account is unmanaged.  
      2. Changes to the password are transparent to SharePoint and are not stored anywhere in SharePoint.
      3. In my opinion, best practice when changing the SQL Server service account password is to shutdown SharePoint whilst this account is worked on; and then only start up the farm's SharePoint servers once the farm's backend is full operational and all services are running again.  This avoids at the least the appearance of numerous critical system and application events appearing in server logs.
  7. SPSUPERR - Change the Farm Super Reader Account Password
    1. Description
      1. Standard domain account.
      2. It is not a service account.
      3. Supports object caching when Publishing feature is enabled for the web application.
    2. Type
      1. Unmanaged.
      2. Though this is an unmanaged account, it's still helpful to use Central Administration Managed Accounts capability so as to test password changes. 
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      3. Launch Central Administration.
      4. Navigate to: CA > Security > General Security > Configure Managed Accounts.
      5. Look for the super reader account, and then click the Edit icon next to the title.
      6. In the Credential Management section, check Change password now.
      7. Next, also in this section, select Use existing password, and then enter the password.
      8. Scroll down, and then click OK.  The page will be busy for less than a minute.
        It may take a few seconds for the password change in AD to propagate. This means that you may likely still be able to enter the old password one or more times here before you get an error message indicating that the password is the wrong one.
      9. That's it.  Nothing more to do.  These are not service accounts.
    4. Summary
      1. Entering the super reader account into Managed Accounts has absolutely no impact: no SharePoint services and applications will obtain the super reader account from Managed Accounts.
      2. SharePoint does not need to authenticate these accounts, since they are impersonated.  See References 4.1 and 4.5 for additional detail on this account.
  8. SPSUPERU - Change the Farm Super User Account Password
    1. Description
      1. Standard domain account.
      2. It is not a service account.
      3. Supports object caching when Publishing feature is enabled for the web application.
    2. Type
      1. Unmanaged
      2. Though this is an unmanaged account, it's still helpful to use Central Administration Managed Accounts capability so as to test and verify password changes. 
      3. Entering the super user account into Managed Accounts has absolutely no impact and no SharePoint services and applications will obtain the super user account from Managed Accounts.
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      3. Launch Central Administration.
      4. Navigate to: CA > Security > General Security > Configure Managed Accounts.
      5. Look for the super user account, and then click the Edit icon next to the title.
      6. In the Credential Management section, check Change password now.
      7. Next, also in this section, select Use existing password, and then enter the password.
      8. Scroll down, and then click OK.  The page will be busy for less than a minute.
        It may take a few seconds for the password change in AD to propagate. This means that you may likely still be able to enter the old password one or more times here before you get an error message indicating that the password is the wrong one.
      9. That's it.  Nothing more to do.  These are not service accounts.
    4. Summary
      1. Entering the super reader account into Managed Accounts has absolutely no impact: no SharePoint services and applications will obtain the super reader account from Managed Accounts.
      2. SharePoint does not need to authenticate these accounts, since they are impersonated.  See References 4.1 and 4.5 for additional detail on this account.
  9. SPWORKFL - Change the Farm Workflow 2013 Service Account Password
    1. Description
      1. Standard domain account.
      2. TBD
    2. Type
      1. Managed.
    3. Procedure
      1. TBD
    4. Summary
      1. TBD
  10. SPSERVICE - Change the Farm Service Application Service Account Password
    1. Description
      1. Standard domain account.
      2. Used as identity for C2WTS, Distributed Cache, Sandbox Code Service, SharePoint Hosted Services and application pools (eg, App Mgmt, BDC, Excel Calc, MMS, Secure Store, UPSA, Visio, Word Auto, etc).
      3. May also be used as identity for Distributed Cache.
    2. Type
      1. Managed
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed.
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Launch Central Administration.
      5. Navigate to: CA > Security > General Security > Configure Managed Accounts.
      6. Look for the Service service account (eg, spService), and then click the edit icon next to it.
      7. In the Credential Management section, check Change password now.
      8. Next, also in this section, select Use existing password, and then enter the password.
      9. Scroll down, and then click OK.  The page will be busy for less than a minute. Once it returns, move on to the next step.
      10. Check Windows Server services on each machine hosting SharePoint.  Start any SharePoint and SharePoint-related services that are not running and that should be running.  In particular, check those services that might be running under the Service service account, such as Distributed Cache (AKA AppFabric Caching Service), Claims to Windows Token Service and so on.
        From experience, the AppFabric Caching Service will restart automatically after updating the Service service password in Managed Accounts. However, the Claims to Windows Token Service will not, and you must restart it manually.
      11. That's it.  You're done.
    4. Summary
      1. The key thing to keep in mind here is that, even though this is a managed service account, it is still useful to check all services using this service account to verify that they did indeed restart successfully.
  11. SPPROFILE - Change the User Profile Synchronization Account
    1. Description
      1. Standard domain account.
      2. Typically used to read AD user profiles and copy that information to SharePoint user profiles.
      3. At a minimum, in order to read AD objects and replicate them to SharePoint, this account requires the Active Directory permission Replicate Directory Changes. This permission enables this service account to read Active Directory objects and to discover whether any of these objects have been changed in the domain.
    2. Type
      1. Unmanaged
    3. Procedure
      1. Change the password in AD Users and Computers as you would normally.
      2. Restart all farm servers on which SharePoint is installed.
      3. Next, remote into any SharePoint server using the SharePoint Setup User Administrator account (eg, spAdmin).
      4. Launch Central Administration.
      5. Navigate to: CA > Application Management > Manage service applications, and then click on the name of your User Profile Service Application (this may be the name).
      6. Then navigate to: Synchronization > Configure Synchronization Connections.
      7. Open the dropdown menu for the appropriate connection listed, and then select Edit.
      8. In the Connection Settings section, enter the new password into the Password and Confirm Password fields.
      9. Test the new password by clicking the Populate Containers button.  
      10. Click OK.
      11. Navigate back to the Manage Profile Service: User Profile Service Application page.
      12. Click the Start Profile Synchronization button.
      13. Select Start Full Synchronization, and then click OK.
    4. Summary
      1. The key things to keep in mind here are that: 1) spProfile is not managed and 2) after changing the password in AD, you will need to return to the user profile service application and update the password used in the synchronization connection.  Once you do that, you're done.

References

  1. General
    1. Initial deployment administrative and service accounts in SharePoint 2013
    2. Account permissions and security settings in SharePoint 2013
    3. Updating passwords on SharePoint 2010
    4. SharePoint 2013 Service Accounts Best Practices! Is there a golden solution for all farms?
    5. Changing SharePoint farm passwords
    6. Managing Passwords for Service Accounts in SharePoint & SQL Server: excellent, thorough discussion. NOTE: his discussion presumes that the server farm account has been granted the necessary AD write privileges for writing password changes entered into SharePoint Managed Accounts back to AD.  
    7. SharePoint 2013: Service Accounts
    8. SharePoint 2013: Service Account Configurations and Permissions

  2. SharePoint Setup User Administrator Account Password Changes
    1. Step by Step: Changing the SharePoint 2013 Farm Account Password
  3. Changing the farm service account
    1. Unable to change SharePoint account password in SharePoint 2010
  4. SharePoint SQL Server Service Account Password Changes
    1. Change passwords for SQL Server services in SharePoint Server 2013
  5. SuperUser Accounts
    1. Configure object cache user accounts in SharePoint Server 2013
    2. SharePoint–Setting the Super User and Super Reader Accounts for All WebApplications in the Farm
    3. Part 5: Object caching
    4. How does SharePoint 2010 uses the SuperReader/SuperUser accounts?: excellent discussion that finally helped me to understand why a password is never requested when entering these accounts into SharePoint.
  6. Service Application Service Account
    1. Change Distributed Cache Service Account in SharePoint 2013 with PowerShell
    2. SharePoint 2013: AppFabric and Distributed Cache Service
    3. SharePoint 2013: Distributed Cache (AppFabrikCache) part 2/2
    4. Manage the Distributed Cache service in SharePoint Server 2013
  7. User Profile Synchronization Account
    1. Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server 2013
  8. Commandlets
    1. Set-SPManagedAccount
    2. Repair-SPManagedAccountDeployment
  9. Miscellaneous
    1. SharePoint 2013: How to deploy a search service application using PowerShell

Notes

  1. Synchronization Service Manager: useful tool for troubleshooting the SharePoint User Profile Service Application.  You'll find it at this folder location:
    \Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell
    Look for miisclient.exe.  It enables you to view the real-time status of UPA processes, among many other things.  I don't use it to manage FIM; just to view status information.  For example, I have used to troubleshoot a UPA that failed to start.  As I tried different troubleshooting steps, I monitored Synchronization Service Manager, watching in real-time to see how far UPA started, before stopping.  It also provides helpful other information, such as confirmation of the Domain Controller that it is connecting to.  If you configured UPA using Auto Detect for DC, you can now determine exactly which DC it is connecting to.  You can also get confirmation of the service account that is running UPA (eg, the farm service account).  This tool is also useful for monitoring startup functionality, after changing the password under which the Synchronization service runs (which is usually the farm server account, eg, spFarm).
  2. The User Profile Synchronization Service (this one is listed just below the User Profile Service) will likely be stopped if it is configured to run under the server farm account, which is usually the case.  You will need to manually start it again and you will likely be prompted to enter the new server farm account password.  Once you do this, it will be in the Starting... state for awhile. Keep refreshing the page for a while to verify that it finally reaches the Started state.
  3. If you first launch a browser as you would normally, and then connect to Central Administration, you may not see the Manage services on server link in the System Settings group.   This is because the browser instance must specifically be running in elevated mode, meaning Run as administrator.  This is the case when you launch CA using the menu option in the Windows Server Start menu.  If you click on this, you are presented with the usual User Account Control prompt.  This is an indication that the application is being run in elevated mode. This icon really just launches IE, and points it to CA, but it does so as an elevated instance of IE.  If you launch a browser normally, and then try connecting to CA, if your current account is a member of the Farm Administrators group in CA, your browser will connect to CA and you will see most of the usual web pages and links in CA.  Except for Manage services on server.
  4. Problem changing the farm service account? Try it this way instead:
    1. Verify that the password is changed in AD - doe this by changing a server service account password.
    2. In elevated SharePoint Management Shell (SMS), execute: Set-SPManagedAccount -UseExistingPassword -Identity DOMAIN\spFarm.  You'll be prompted to enter a new password.  This will take five minutes or more to complete.
    3. In the same SMS, execute: Repair-SPManagedAccountDeployment.  If the passwords are in sync, this will complete silently and return the prompt.  Keep this shell open.
    4. In elevated DOS command shell, execute: IISRESET.
    5. In the SMS, execute: Repair-SPManagedAccountDeployment.  As a last check.

Thursday, October 13, 2016

SharePoint 2013: The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly.

Problem

You create a simple notification workflow (2010 version) for a list.  The workflow is supposed to send an email to the individual who originally created the list item if a certain column, say, Status, is changed to a specific value, say, Completed.  All the workflow needs to do is send an email to the Created By person and include in this email all of the list item column values:
Email Current Item:Created By
and the Workflow start options are: Start workflow automatically when an item is changed.  The format of the Created By field returned to the workflow lookup is Display Name.  You check the workflow and there are no issues.  You publish the workflow without any issue.  You then test the workflow by changing the Status column for an item to Completed.  The workflow appears to complete successfully.  However, the intended recipient does not receive any email from the list; and when you check the workflow history, you see:
The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly.
This result is repeatable.  What's curious is that when you yourself create an entry in this list, and repeat the test on your own entry, an email is in fact sent out, and this result too is repeatable.  You commence troubleshooting.  NOTE: these troubleshooting steps do not include all ancillary steps explored, but review and list the actions performed in the main troubleshooting thread.

Troubleshooting

  1. Facts and Initial Observations
    1. Emails can be sent from other workflows and alerts in other site collections in the content web applications.  This indicates that farm level email settings are configured correctly
    2. Emails from the target workflow can in fact be sent if the workflow is triggered on the list entry this administrator created in the target list.  This indicates that the workflow is in fact functioning correctly and, specifically, that the workflow's email action is correctly configured and functioning.
  2. Check User Workflow Document content type Title property
    1. Using SharePoint Designer 2013, verified that the Title property of this content type is set to Optional. See Reference 1 for additional detail on the importance and impact of this content type property on workflow functioning.
  3. Change list Title property to Optional
    1. As administrator, changed list Title property to Optional.
    2. Removed all versions of workflow from list.
    3. Republished workflow to list
    4. Tested
    5. Email still not sent and fails with same error in Workflow History List.
  4. Add Log step to capture data
    1. Added step to workflow to log all different types of Created By formatted (ie, "Return field as"), including: String, Display Name, Email, Login and ID, to the Workflow History List.
    2. Removed all versions of workflow from list.
    3. Republished workflow to list
    4. Tested on original user not receiving email.
    5. Observed that the user's email address was not displayed but instead the user's login was shown. What was shown looked something like this:
      Created By (String): i:0#.w|DOMAIN\FIRST.LAST
      Created By (Display): FIRST LAST
      Created By (Email): i:0#.w|DOMAIN\FIRST.LAST
      Created By (Login): i:0#.w|DOMAIN\FIRST.LAST
      Created By (ID): [some integer]
    6. Tested workflow on my own list entry
    7. Observed that in contrast to this user, my email was shown. What was shown looked something like this:
      Created By (String): i:0#.w|DOMAIN\MYFIRST.MYLAST
      Created By (Display): MYFIRST MYLAST
      Created By (Email): MYFIRST.MYLAST@SOMETHING.COM
      Created By (Login): i:0#.w|DOMAIN\MYFIRST.MYLAST
      Created By (ID): [some integer]
  5. Check ULS
    1. Found curious entry
      The e-mail address 'FIRST LAST' contains illegal characters.
      also saw other curious messages (under same correlation ID):
      CSPRequest::SendMail. Error Detected. SendMail failed.
       
        Cannot complete this action.  Please try again.<nativehr>0x80004005</nativehr><nativestack></nativestack>
       
        System.Runtime.InteropServices.COMException: Cannot complete this action.  Please try again.<nativehr>0x80004005</nativehr><nativestack></nativestack>, StackTrace:
       
      SPUtility.SendEmail: Unmanaged SPRequest.SendMail failed
  6. Check server event logs
    1. Found no events occuring at the time of the workflow being launched
    2. Found no related events in system or application logs
  7. Check user's profile in Active Directory
    1. Verified that the user's email field in his AD profile did have an email address entered.
  8. Check site collection's hidden User Information List
    1. Found that the user was listed.
    2. No email address was listed for the user in this list.
  9. Check user's profile in User Profile Service
    1. Found that the user's profile in UPS did not have an email entered.
    2. Also found that the Department value was blank.
    3. Entered the user's email address into his profile and also entered the appropriate value for the user's Department.
    4. Performed Full Crawl on User Profiles.
    5. Tested workflow again on user.
    6. Email still not sent and fails with same error in Workflow History List.
    7. Also found that what was logged to Workflow History List for user was same as found in step 3.5, above.  Namely, the value returned for Email was still the user's login string.
  10. Change format of user lookup in Created By to Email
    1. Edited workflow lookup for user to return as Email.
    2. Saved workflow
    3. Removed all versions of workflow from list.
    4. Published edited workflow.
    5. Tested on user's entry.
    6. Still observed error.
  11. Perform Full Crawls of both User Profiles and My Sites
    1. Performed full crawls of both User Profiles and My Sites content sources.
    2. Removed all versions of workflow from list.
    3. Published workflow to list
    4. Tested on same user.
    5. This time, the user's actual email address is displayed for Created By (Email): log entry and no error is listed.

Solution

  1. Make sure that for sending emails via workflow that the user's login is entered (via workflow lookup) as type Display or Email.
  2. Make sure that the user's profile information in UPS is complete.  In particular, verify that the user has an email entered into his or her UPS profile.
  3. If any changes to the user's profile information in UPS are made, followup with full crawls of both user profiles and My Sites content.

Summary

There are many possible causes for this error message when launching workflows that send emails. In this posting, I have documented one possible cause.  In the future, I will add checks of user profile information in both AD and User Profile Service to my workflow troubleshooting; and if any profile changes are made to these sources, I followup with Full Crawls of both User Profile and My Site content sources.

References

Friday, October 7, 2016

SharePoint 2016: Databases running in compatibility range, upgrade recommended

Problem

You have perform an initial core install of SharePoint 2016 onto a single server.  You have not yet created user content web applications or instantiated any service applications. Later, you check Health Reports and see the following warning:
TitleDatabases running in compatibility range, upgrade recommended
Severity2 - Warning
CategoryConfiguration
ExplanationThe following databases have versions that are older than the current SharePoint software, but are within the backwards compatible range:
[central admin content database]. 
RemedyTo achieve optimal results from these databases, use Upgrade-SPContentDatabase to upgrade Content databases, or psconfig.exe to upgrade other databases. For more information about this rule, see
http://go.microsoft.com/fwlink/?LinkID=142697 
Failing Servers
Failing ServicesSPTimerService (SPTimerV4)
Rule SettingsView
Understanding this to be a content database, you open an elevated SharePoint Management Shell and execute the following commandlet: Upgrade-SPContentDatabase [central admin content database]. However, this returns an error: The content database could not be found.  This doesn't make sense. You begin troubleshooting.

Troubleshooting

  1. Check database status:
    1. In Central Administration, navigate to: Upgrade and Migration > Upgrade and Patch Management > Review database status.
    2. Found that the Central Administration content database was listed as Database is in compatibility range and upgrade is recommended.
  2. Get database instance
    1. In an elevated SharePoint Management Shell, executed Get-SPContentDatabase: this returned nothing.  This indicated that the farm content database is not considered to be a content database per se, even though it is in fact storing content.
    2. Execute Get-SPDatabase | ft -auto: this returns all databases: the farm content database and the farm configuration database.
  3. Execute PSCONFIG
    1. In an elevated SharePoint Management Shell, executed: Psconfig.exe -cmd upgrade -inplace b2b -wait -force.  Completed successfully.
    2. Navigate to: Upgrade and Migration > Upgrade and Patch Management > Review database status.  Found that 

Solution

  1. Execute PSCONFIG.

References

Monday, September 26, 2016

SharePoint 2013: How to move a website

Introduction

This posting documents the typical steps for moving a website, or "web" in Microsoft terminology, to a new location, whether in the same web application or a different web application.  The website here is a subwebsite to an existing website or to the root site collection website.  The focus will be on using PowerShell.  The general steps are: 1) identify the web template of the source website; 2) export the website; 3) create a new blank website at the destination having the same web template; and 4) import the source website over the destination blank website.

Procedure

  1. Note down the core URL of the website you want to move.
  2. As a farm administrator, log into any SharePoint server of the farm containing the website you want to move.
  3. Launch an elevated SharePoint Management Shell.
  4. Execute the following commandlets to identify the source website's web template:
    $web=Get-Spweb -Identity "[website core url]"
    $Web.WebTemplate
    $web.WebTemplateId
  5. Note down the WebTemplate and the WebTemplateId that are returned. Combine these using the number symbol "#".  For example, if the WebTemplate returned was "STS" and the WebTemplateID returned was "1", combine these as "STS#1".
  6. Execute the following commandlet to export the source website, including all versions and its security configurations:
    Export-SPWeb -Identity "[website core url]" -Path "[eg D:\MyExportFolder\MyWebExport.cmp]" -IncludeVersions "All" -IncludeUserSecurity -CompressionSize 1000 -Force
  7. If moving to a new farm, log into any SharePoint server on the destination farm, and then copy the export file to this server.  Otherwise remain logged into the current SharePoint server.
  8. Execute the following commandlet to create a new website using the same web template that you found earlier:
    New-SPWeb -Identity "[Core URL of the new website]" -Template "[SourceWebTemplate]" -Name "[title of new website]"
  9. Now execute this commandlet to import the exported website:
    Import-SPWeb -Identity "[new website URL]" -Path "D:\][pathtoyourfile]\[exportfilename].cmp"
  10. You're done.  Note that the only user to this website will be you; and the usual user groups (Visitors, Contributors, etc) have not yet been created.

References

Notes

  • The "-CompressionSize 1000" parameter helps ensure that the export will comprise a single file.  The number "1000" is in MB.

Tuesday, September 20, 2016

SharePoint 2013: This form cannot be opened in a web browser.


Problem

This message appears to be associated with several different problems.  The particular problem discussed here involves experiencing this message when trying to run a 2010 workflow.  This posting captures the steps undertaken to resolve this problem.
Created a new 2010 workflow using SharePoint Designer 2013 (SPD), saved it and published it successfully.  No errors were encountered when performed a "Check for Errors" in SPD.  When then tried to execute the workflow, saw the following message:
After clicking the Close button, then saw this message:
This experience was repeatable.

Troubleshooting

  1. Try to repeat problem
    1. Found that problem occurred whenever tried to run the workflow.
  2. Try workflows in other lists and site collections
    1. Found that 2010 workflows created and deployed to lists in other site collections worked fine.  Problem localized to target site collection.
  3. Try other accounts
    1. Found that problem persisted no matter what account used to create and deploy and run workflow.
  4. Check ULS
    1. Found several messages ( among 20 associated with problem correlation ID)  indicating potential access or permissions issue: 
      1. Cannot open file ".../Workflows/SendStatusUpdate/SendStatusUpdate.xsn".
      2. System.Runtime.InteropServices.COMException: Cannot open file "Workflows/SendStatusUpdate/SendStatusUpdate.xsn".,...
      3. The XSN is null and its not a cross server issue. Most likely a permission issue
  5. Check Workflows document library permissions
    1. Found that the Workflows document library had same permissions as website.
    2. Found that versioning was enabled.  Disabled this, tried to run workflow again: still got error.
    3. Found that two workflow files, the .XOML and .XSN files, were listed in the document library's Manage files which have no checked in version listing, when viewed under different accounts (one standard and another an admin).  Using the other admin account, took control over the files in the hope that the other admin account could then check them in.  After performing this operation, experienced error when attempting to navigate back to this page: could not bring page up; in fact, also could no longer navigate to the document library's Settings page.  Since this was root site collection website, and on development, performed restore of site collection database to return to initial state: was able to get back to library's Settings page and also view the no checked in version listing again.
  6. Check Website Permissions
    1. Verified that account used to create the workflow, an admin account, was a member of the site collection administrator group.  
    2. Added the account used to create the workflow, an administrator account, to the Full Control group of the website containing the list.  Afterwards, noted that Limited now appeared next to the Full Control designation in the website's permissions listing (showed Full Control, Limited).  After this, added admin account to website permissions and specifically granted Full Control: the Limited designator no longer appeared.
  7. Explore issue in SharePoint Designer
    1. In SPD, connected to website using an admin account.  Then in the left Navigation panel, expanded All Files > Workflows, and then selected the target workflow.  The right action panel listed the constituents of this workflow (four items).  Two of these items, the .XOML and .XSN, were indicated as being checked out.  Selected the .XSN file and then clicked the Delete button.  This resulted in an error prompt:
      Microsoft SharePoint Designer
      Server error: The file "[website URL]/Workflows/WorkflowName/WorkflowName.XSN" is checked out for editing by [another admin account].
    2. Next, clicked the Check In button.  This resulted in another error prompt:
      Microsoft SharePoint Designer
      We can't do that for you because the file is no longer checked out or has been deleted. 
    3. In SPD, created and published another test workflow attached to same list and attempted to run: experienced same type of error.
  8. Internet Research
    1. Conducted search on "SharePoint 2013 We can't do that for you because the file is no longer checked out".  This didn't seem to apply as it essentially discussed checking files in and this was already proven impossible using SPD capabilities.
    2. Conducted search on "SharePoint 2013 This form cannot be opened in a Web browser. To open this form, use Microsoft InfoPath".  All of the search results involved Infopath issues.  These didn't seem to apply. Reference 3 indicated that the SharePoint Server Enterprise Site Collection features should be activated.  Checked this and found that it was activated. Reference 4 indicated browser configuration and Infopath issues; however, these didn't seem to apply.
    3. Conducted search on "SharePoint 2013 workflow files checkin".  Reference 5 seemed to provide the right clues: it discussed the same error messages but associated with content type configuration.  This seemed to have more likelihood of applying to current situation.  Returned to troubleshooting.
  9. Check Workflows document library content type configurations
    1. Launched SPD, expanded All Files to Workflows document library, right-clicked on Workflows document library and chose Properties...  Reviewed Workflows tab in action panel. Reviewed Content Types section.  Did not find Document content type (as discussed in reference), but found User Workflow Document content type instead. Clicked on User Workflow Document.  User Workflow Document tab appeared. In Customization section, clicked on Edit content type columns.  Found that Title property was set to Required.  
    2. Selected Title property, and then clicked on Administration Web Page button displayed in SPD.  Changed setting to Optional, and then clicked OK.
    3. Created new, simple workflow attached to target list (wrote to log only).  Manual trigger. Completed successfully.  Repeated testing and again completed succesfully.  Problem determined to be resolved.

Solution

  • Check the website's Workflows document library User Workflow Document content type and ensure that its Title property is set to Optional.
  • If making this change still results in the error message, try creating a new workflow to the same list.  The new workflow must have a different name.

References

  • This document folder does not normally appear by default, when viewing a website's Site Contents page.  To make it appear, the document folder's Hide from browser General Setting must be disabled.  To do this:
    1. Launch SPD
    2. Connect to the target website
    3. In the left Navigation panel, scroll down to the Workflows document folder.
    4. Right-click on this folder, and then select Properties...
    5. In the right Action panel, look for the Settings section.
    6. Uncheck the Hide from browser setting.
    7. Save.
  • tbd


Friday, September 16, 2016

SharePoint 2013: How to Connect a Filter to a Chart Web Part


Introduction

In this posting, I will walk you through the process of connecting a Choice Filter web part to a Chart web part so that the range of data shown in the chart depends on a user selection. The chart type will be a pie chart, and the filter type will be the Choice Filter web part. Interestingly, the Choice Filter web part won't be connected to a list that in turn is connected to a chart web part.  Instead, the filter will be connected directly to the chart web part itself.  This can be done because the chart web part has the capability to perform its own filtering on the datasets it consumes.  Furthermore, it can also consume filter values that it will then apply to the datasets it has consumed.  All of the steps for accomplishing this will be discussed here.  Note: these steps require that you have at least Design permission level to the page containing the web parts.

Background

The scenario that will be explored here involves enabling a user to select different sets of data associated with routine monthly SharePoint patching and then see the selected data set displayed in a pie chart. A set of data involves the aggregated times associated with eight patching tasks:
  1. Preparation
  2. Operating System Update Installation (OSU)
  3. SharePoint Update Installation (SPU)
  4. Run Get-SPProduct all SharePoint Servers (GSP)
  5. Run PSCONFIG all SharePoint Servers (PSC)
  6. OWA Update Installation and OWA Reconfiguration (OWA)
  7. Miscellaneous Tasks (Misc)
  8. Review and Regression Testing (Rev)
These are the general tasks performed every month for SharePoint farm patching.  The aggregate total times captured from such tasks are typically recorded to a list having a normalized transactional schema, where values are in minutes, as shown in Table 1 below.  These are the times associated with patching two SharePoint 2013 farms.  Each row represents a single dataset.
Table 1
Title Date Prep OSU SPU GSP PSC OWA Misc Rev Total Include
Patching: production 7/16/2016 0 192 105 139 195 6 0 60 11.52 Yes
Patching: Development 8/10/2016 30 117 124 188 38 9 0 64 9.35 Yes
Patching: Production 8/20/2016 37 144 133 31 35 16 0 36 6.93 Yes
Patching: Development 9/14/2016 10 131 127 120 95 7 0 55 8.97 Yes
The OSU aggregate is the total time involved with patching all farm Windows servers; SPU is the aggregated time associated with updating all farm SharePoint servers; Rev is the aggregated time associated with reviewing and regression testing; and so on. The times associated with these tasks are recorded for process monitoring and improvement purposes.  This sort of data listing follows the standard tabular format for related datasets (having a common X-value):
X-headerYA-HeaderYB-HeaderYC-Header
X1YA1YB1YC1
X2YA2YB2YC2
X3YA3YB3YC3
The data in Table 1 can be straightforwardly displayed in a chart object.  The Date column provides the X-value and the Prep, OSU, SPU, PSC, OWA, Misc and Rev columns provide the Y-values. Entering this data into a SharePoint list and connecting a chart object to this data results in a typical line chart.
This approach works fine for charting table data as lines. However, if you want display data in a pie chart, you have to reformat the data.  Pie charts do not display multiple datasets, but only one dataset at a time.  This means that a pie chart can only represent the Y-values of a dataset, and not the X value; in other words, a pie chart displays the values for a single row of Table 1.  The process for transposing data from a line chart to a pie chart runs like so:
  1. Choose a particular dataset (set of X,Y values)
  2. Remove the X-values, leaving the Y-values (YA1, YB1, YC1...)
  3. Identify the column headers and pair them with the Y-values
In other words, create a new table having just two columns and listing the values like so:
Item Value
YA-HeaderYA1
YB-HeaderYB1
YC-HeaderYC1
The first column does not represent X-values, but contains the column headers from Table 1.  These then become the pie chart labels for the pie slices.  The second displays the Y-values of the dataset.  These values are used to determine the relative sizes of the pie slices.  Therefore, if you wanted to display in a pie chart the task times for a patching session, you do it for one date at a time, building the list like so (Table 2):
Table 2
Task Duration
Prep0
OSU192
SPU105
GSP139
PSC195
OWA6
Misc0
Rev60
where this is the data for the patching session conducted on 7/16/2016, as shown in Table 1. To display multiple patching sessions in a pie chart, requires adding the data from these sessions to Table 2 and also adding some columns to it as well that enable the table to be filtered for a specific dataset.  The general process is:
  1. Add an additional column to the table that identifies the patching session for the dataset.  This is effectively the X-value for the dataset Y-values.  Call it the Session column, and it will be used to filter for a specific dataset.
  2. Add an additional filter column to identify whether a data item should be included in the chart.  This is useful when, perhaps, a particular update session only need to engage in some tasks or was a one-off that you don't want to include in your general process improvement data capture.
  3. Also add a column that provides additional explanation or definition of the task, calling it the Definition column.
  4. Lastly, reformat the Y-value headers to make them more readable and so that they can be conveniently sorted.
Making these modifications results in Table 3, below.
Table 3
Session Task Duration Include Definition
7/16/20161) Preparation0YesReview all updates
7/16/20162) OS Updates192YesInstall Operating System Updates
7/16/20163) SP Updates105YesInstall SharePoint Patches
7/16/20164) Get-SPProduct139YesRun Get-SPProduct
7/16/20165) PSCONFIG195YesRun PSCONFIG
7/16/20166) OWA Updates6YesInstall OWA updates
7/16/20167) Miscellaneous0YesMiscellaneous tasks
7/16/20168) Review60YesTesting and verification
8/10/20161) Preparation0YesReview all updates
8/10/20162) OS Updates192YesInstall Operating System Updates
8/10/20163) SP Updates105YesInstall SharePoint Patches
8/10/20164) Get-SPProduct139YesRun Get-SPProduct
8/10/20165) PSCONFIG195YesRun PSCONFIG
8/10/20166) OWA Updates6YesInstall OWA updates
8/10/20167) Miscellaneous0YesMiscellaneous tasks
8/10/20168) Review60YesTesting and verification
8/20/20161) Preparation0YesReview all updates
8/20/20162) OS Updates192YesInstall Operating System Updates
8/20/20163) SP Updates105YesInstall SharePoint Patches
8/20/20164) Get-SPProduct139YesRun Get-SPProduct
8/20/20165) PSCONFIG195YesRun PSCONFIG
8/20/20166) OWA Updates6YesInstall OWA updates
8/20/20167) Miscellaneous0YesMiscellaneous tasks
8/20/20168) Review60YesTesting and verification
9/14/20161) Preparation0YesReview all updates
9/14/20162) OS Updates192YesInstall Operating System Updates
9/14/20163) SP Updates105YesInstall SharePoint Patches
9/14/20164) Get-SPProduct139YesRun Get-SPProduct
9/14/20165) PSCONFIG195YesRun PSCONFIG
9/14/20166) OWA Updates6YesInstall OWA updates
9/14/20167) Miscellaneous0YesMiscellaneous tasks
9/14/20168) Review60YesTesting and verification
Note that the Session column lists the denormalized X-values associated with dataset Y-values.  By listing the X-values this way, this column can be used for filtering purposes.  By filtering for a specific date in this column, it's possible to extract a set of Y-values associated with a specific patching session.  In other words, if Table 3 is filtered by a particular date, one effectively gets back a table like Table 2.

In summary, this is the process you need to work through in order to get the data prepared. Once you have a list like Table 3 created, you're ready to configure a chart to use that data.  In the next section, you'll walk through the steps for accomplishing this.

Procedure

Step 1: Define Chart web part Filter Parameters
  1. Drop the Chart web part onto a page.
  2. Click Data & Appearance.
  3. Click Connect Chart to Data.
  4. Select Connect to a List, and then click the Next button.
  5. Select the website in the site collection containing the denormalized list, select the list, and then click the Next button. You'll now see your list displayed.
  6. Look up at the top of this list: do you see Filter Data? Click the arrow to expand it. This will reveal filters that you can define. Assuming that you have created a list having column names as shown in Table 3, configure the first parameter like so:
    1. Parameter Name: Session
    2. Type: DateTime
    3. Default value: 7/16/2016
  7. Now let's also implement the Include parameter. One thing: when you create this column, you selected the Yes/No type. Though it doesn't actually indicate this, it's implemented as a Boolean. When used in a list, and when you access the list in SharePoint, the value that you see for this column is Yes or No. But it is implemented as Boolean, but is not surfaced in that way. However, the Chart web part recognizes that column as in fact Boolean, and the values that it will show for that column are True and False. You don't need to change your list values, but you do need to account for this when specifying default or filter values.
    1. Parameter Name: Include
    2. Type: Boolean
    3. Default value: True
  8. Click the Preview Data button. This filters the list based upon the filter parameters you configured.
  9. Click the Next button. This page helps you configure a range of different chart aspects, including the data series' you want to present. For our needs, all you need to do is configure the Series Type, which should be Pie. Select that.
  10. Now click the Finish button. The pie chart will then be displayed. It needs some cleaning up, so let's do that next.
Step 2: Clean up the Pie Chart Display
  1. Click Advanced Properties. The first thing to do is configure a "collected slice," or a slice that contains other pie slices having less than some amount. Doing this helps clear up the clutter associated with having a number of very thin slices and their annotations all crammed together.
  2. From the Select an Element panel, select Series, and then scroll down to the bottom, to the Misc section. The configure as follows:
    1. CollectedThreshold: 10
    2. CollectedThresholdUsePercent: False
    3. CollectedThresholdExploded: True
    Like so:
  3. Now, from the Select an Element panel, select Chart (root element), and then scroll down to the bottom to the Image section. Then configure as follows:
    1. Height: 450
    2. Width: 650
  4. Now, from the Select an Element panel, select Series again, and then scroll down to the bottom, to the Misc section. The configure as follows:
    1. PieLabelStyle: Outside
    2. LabelsHorizontalLineSize: 0
  5. Staying on the Series element, scroll up until you see the MapArea section. Configure as follows (include the "#"):
    1. ToolTip: #VALY/#TOTAL (#PERCENT)
  6. This completes chart cleanup. You can certainly do far more here, but this is enough for our purposes. In the next step, you will add and configure a Choice Filter web part.
Step 3: Add and Configure a Choice Filter
  1. Put the page back in Edit mode.
  2. Drop a Choice Filter web part onto the page.
  3. Select Edit Web Part from the Choice Filter dropdown menu (hover the cursor over the web bar to see the dropdown appear).
  4. In the Filter section, enter a name for the filter and then enter a list of dates. These dates should be exactly the same as what you entered into the SharePoint list. Also enter a date that will be the default date.
    The default date is pushed into the Chart web part, when the page is instantiated and streamed to the user's browser. Having a default value ensures that the chart web part will display a chart when the user first connects to the page.
  5. Click OK. Now let's connect this filter web part to the chart web part.
Step 4: Connect the Choice Filter to the Chart
  1. Open the Choice Filter dropdown menu again, and then this time point to Connections, then point to Send Filter Values To, and then select the name of your chart web part.
    A dialog will appear. Note that the names of the parameters that appear in the dropdown on this dialog. Our Session parameter appears first.
  2. Select the Session parameter, and then click OK. Note the date that appears now in the Choice Filter web part.
    This is the default you entered previously.
  3. Click the small filter icon to the right of the Choice Filter web part. The Select Filter Value(s) dialog appears.
  4. Select another date, and then click OK. The dialog closes, and the page is refreshed, now displaying the data associated with that session date!
  5. At this point, you're set: you don't need any further significant configuration. The rest is customization.
  6. Here's a more cleaned up version:
    Note that to remove the toolbar, you'll need to edit the web page markup and set the Toolbar parameter of the Chart web part to False.  See the references for additional detail on this. Unfortunately, I don't know how to make the chart Title also update per the Choice filter - the Title text doesn't accept keywords.  If you know of a simple way, add your comment!  For additional hints and guidance on customization, see 

References

  • If you should subsequently edit the Choice Filter web part again - maybe changing its title or some such - don't be surprised that this seems to break the connection between this web part and the Chart web part.  I find this occurs almost every time.  Even if I'm in SharePoint Designer and make a single change to a parameter (e.g., changing True to False), and carefully save the file so that nothing else is changed - even this causes the connection to break.  The fix is simple: just rebuild the connection in the usual way.
  • You can also implement a similar capability using the List Filter instead.  This takes a list of values from a column in a SharePoint list that you specify.  This approach enables you to update the filter parameter list by just editing a list rather than having to edit a web page (which requires Design level permission).

Wednesday, September 14, 2016

SharePoint 2013 TIP: how to easily rename and retitle a website

You can easily rename and re-title a website by getting an instance of the website object and setting its Name and Title properties, like so:

$web=Get-SPWeb -Identity "http://MyFarm.com/MyRootWebsite/MyWebsite"
$web.Title="My New Website Title"
$web.name="MyNewWebsiteName"
$web.Update()

which gives

http://MyFarm.com/MyRootWebsite/MyNewWebsiteName

References

Notes

  • This works for subwebsites off the root.
  • To rename the site collection, see the references above.

Wednesday, August 31, 2016

SharePoint 2013 TIP: How to create a new website using PowerShell

Sometimes it is more convenient to create a new website (or "Web" in Microsoft terminology) via PowerShell rather than using browser-based methods. I don't mean a new "site", which is Microsoft terminology for "site collection."  I mean just a website that is sub to another website or maybe sub to the site collection's root website.  The commandlet for creating new websites is New-SPWeb.

Procedure

  1. Identify the following key website parameters:
    1. URL of the existing website that you want to us as a container for the new website.  Don't include the final "/" when noting down this URL.
    2. Name of the new website.
    3. Web template to be used for the new website.  These will be in the format "STS#0" or "CMSPUBLISHING#0," and so on.  For a listing of these and their descriptions, see the references below.
  2. Open an elevated SharePoint Management Shell, and then execute the following commandlet:
    New-SPWeb -Identity "[full URL of the new website]" -Template "[templateNameAndID]" -Name "[title of new website]"
  3. That's it.  It will take a minute or two to complete.  You're done.  See the Notes section below for useful additional aspects about this method.

References

  • In Microsoft terminology, this is the hierarchy of website terms:
    • Web Application
    • Site Collection
    • Web
  • Don't know the template used by an existing website?  Easy PowerShell. Get an instance of the website, and then interrogate its webtemplate property like so:
    $web=Get-SPWeb -Identity "[website core URL]"
    $web.webtemplate
    $web.webtemplateid
    Note that you need to get both the webtemplate and the webtemplateid.  Also, by "core url" I mean the URL without the web page file name or the folder it's located in.
  • If you run the above commandlet to create the new website, the website permissions will be configured to inherit from the parent website.