Saturday, July 30, 2016

Adobe Professional: Web Page Content Prints as Garbled Characters

Problem

You print a web page using Adobe Professional.  When you look at the web page, all of the body text and headers print as if the character mapping was garbled, making the entire page unreadable.  For example, instead of this:
It is recommended that you take a moment to review this confirmation statement carefully, making note of your confirmation number, and print a copy for your records.
you see this
Interestingly, if you copied this text directly from the PDF document, and pasted it into Notepad,  you would in fact get the original text.  This indicates that the underlying character codes are correct; it's just how Adobe is interpreting them is the problem.  The solution to this is simple and involves some easy configuration steps.

Solution

  1. Go: Start > Devices and Printers.  The Devices and Printers control panel appears.
  2. Double-click on the Adobe PDF icon (or whatever you have named it as).
  3. From the Printer menu, select Properties. The Adobe PDF dialog appears.
  4. On this dialog, click the Preferences button.  The Adobe PDF Printing Preferences dialog appears.
  5. Select the Adobe PDF Settings tab; then, from the Default Settings dropdown, select the High Quality Print item; and then, uncheck the Rely on a system fonts only; do not use document fonts setting.
  6. Now select the Paper/Quality tab.
  7. On this tab, click the Advanced button.  The Adobe PDF Convert Advanced Options dialog appears.
  8. Look down the list of configuration items as: Graphics > Image Color Management > TruType Font.  Change this setting to Download as Softfont.
  9. Then, on this same dialog, expand: Document Options > PostScript Options > TrueType Font Download Option, and then select Native TrueType.
  10. Click OK.  The changes are implemented immediately.

References


Thursday, July 21, 2016

SharePoint 2013: The following users do not have e-mail addresses specified

Problem

You create a new alert on a list for a group of users.  After configuring the alert, and then clicking OK, you see the following error message:
Sorry, something went wrong 
The following users do not have e-mail addresses specified: 
    -[Person M]
    -[Person N]
    -[Person O]

Alerts have been created successfully but these users will not 
receive notifications until valid e-mail or mobile addresses 
have been provided. 

Technical Details 

Troubleshoot issues with Microsoft SharePoint Foundation. 

Correlation ID: 31fc919d-f366-2064-a6e5-34668d1de1b7 

Date and Time: [date/time]
You then begin troubleshooting.

Troubleshooting

  1. Repeated creating the alert: same error.
  2. Checked alert membership: Go: Settings (Gear icon) > Site settings > Site Administration > User Alerts.  Cycled through all users in dropdown list: all other users configured for the alert appear except for those shown above.
  3. Create alert on mirror development farm instance: same error.
  4. Created alert for ad hoc select of users and those listed above: alerts for those users listed above generated error, but all others were created without error.
  5. Manually edit user profile with email: Go: Central Administration > User Profile Service > People > Manage User Profiles > [search for last name] > [entered email] > saved.  Same error.
  6. Manually initiate new User Profile content Full Crawl: same error
  7. Manually initiate new Profile Synchronization: same error.
  8. Perform web search on error text: found this posting and others (listed below in References section).
  9. Ran this command: Get-SPUser –Web  "http://webappurl" | Set-SPUser –SyncFromAD.  No more error when creating alert.

Solution

  • If standard methods fail, run the command in an elevated SMS.

References

  • SMS: SharePoint Management Shell.
  • When running this commandlet, it may will generate a lengthy error list.  Not to worry: this list is the result of the commandlet not being able to synchronize an account in SharePoint with the an account in AD.  This may be due to the account being a service account, which likely does not have an email address configured for it, or due to the person no longer being a member of the filtered AD group that the UPA connection interrogates.  Thus, I have found this commandlet useful in generating a listing of "orphaned" users.

Monday, July 18, 2016

SharePoint 2013: Search Service Application and Common PowerShell Commands


  • Get-SPEnterpriseSearchServiceApplication
    • Returns all Search service application instances in farm
    • Useful for quickly getting the SSA name
    • If only one SSA, returns SSA object that can be used directly in another command. For example: Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication).
  • Get-SPEnterpriseSearchCrawlContentSource
    • To get a listing of all content sources:
      • Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) | ft -auto
    • To get an instance of a specific content source:
      • $SSACS1= Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) -Identity 1
      • $SSACS1= Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) -Identity "Local SharePoint sites"
    • To get the crawl status of all content sources:
      • Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) | ft name,crawlstatus -auto
    • To get the crawl status of a particular content source;
      • (Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) -Identity 1).CrawlStatus
    • To stop the crawl of a particular content source:
      • (Get-SPEnterpriseSearchCrawlContentSource -SearchApplication (Get-SPEnterpriseSearchServiceApplication) -Identity 1).StopCrawl
      • Note: this doesn't "force" the crawl process to stop, by, say, terminating it abruptly.  On the contrary, if you run this command, and then quickly navigate to the Central Administration > Search Administration > Manage Content Sources page, you'll see the status change from Crawling Full (or Crawling Incremental) to Stopping and then eventually becoming Idle.
  • Get-SPEnterpriseSearchStatus
    • Returns status of all SSA components.  Basically, shows in text what you see when you navigate to the Search Administration page in Central Administration.
    • If you have just one SSA in the farm, use like so:
      • Get-SPEnterpriseSearchStatus -SearchApplication (Get-SPEnterpriseSearchServiceApplication) | ft -auto
      • Get-SPEnterpriseSearchStatus -SearchApplication (Get-SPEnterpriseSearchServiceApplication) | ft name,state,level,details -auto
  • Get-SPEnterpriseSearchServiceInstance
    • Used without any arguments, returns listing of all servers running a Search service instance - Osearch15, not foundation.
References

Friday, July 15, 2016

SharePoint 2013 TIP: export Windows Server settings after SharePoint deployment

After successfully deploying SharePoint to the first SharePoint server in the farm, I would like to save the Windows Server settings so that I can build the next SharePoint farm servers identical to the first one.  This can be done in several ways, one method is to save the Windows Server configuration settings to a file that can later be imported via PowerShell.

Procedure

  1. Launch Server Manager.
  2. Click Add roles and features.
  3. Click through until you get to the Features selection.  At this point, if you haven't enabled anything, the Next button will be disabled.  You need to get past this panel in order to reach the export settings capability.
  4. Enable any feature, and then click Next.  The Confirmation panel appears.  On this panel, at the bottom, you'll see the Export configuration settings link.  
  5. Hover the cursor over this link to see the PowerShell commandlet needed to import this file at another server.
    .
  6. Now click the link.  The file will be saved to your default home folder.

References

SharePoint 2013: easily hide and show list form fields using PowerShell

Introduction

There are a few different ways to make list forms display only the columns you want to display and not display the others.  One way is to create custom New, Edit and Display list forms presenting only those fields that you want presented.  This can be accomplished using SharePoint Designer 2013.  Another way is to employ a list field's ShowInDisplayForm, ShowInNewForm and ShowInEditForm properties.  This way can be accomplished using just a few lines of PowerShell script.

The commandlet that we will be using in this posting is primarily Get-SPWeb, which is needed to get an instance of the website object.  Once obtaining an instance of that object, we'll need to drill down to an instance of the appropriate website list object and then an instance of the appropriate field object in that list object.  This posting shows you how.

Procedure 

First, a test list, Assessments, was created having five custom fields in addition to the default Title field.
Clicking on the new item link displays the usual default NewForm, having all the expected fields:
Now, let's consider the case where we want routine users to only fill out the Title and Comments fields when submitting a new assessment request.  You could add comments to the other fields directing users not to populate these other fields with data, but better UI design is to not display them at all when it's unnecessary.  Let's hide the Reviewer, Status, Assessment Date and Priority fields from the list's NewForm, which is the form that will be used by ordinary users.  Now let's get an instance of the website:
$SPWeb = Get-SPWeb "http://[yourwebsite]"
Next, get an instance of the target list in that website:
$SPList = $SPWeb.Lists["Assessments"]
Now, we need to get instances of all fields we want to hide:
$SPField1 = $SPList.Fields["Reviewer"]
$SPField2 = $SPList.Fields["Status"]
$SPField3 = $SPList.Fields["Assessment Date"]
$SPField4 = $SPList.Fields["Priority"]
This enables us to set each field's ShowInNewForm property, like so:
$SPField1.ShowInNewForm  = $false
$SPField2.ShowInNewForm  = $false
$SPField3.ShowInNewForm  = $false
$SPField4.ShowInNewForm  = $false
Though these instances of the fields' ShowInNewForm property have been set, this setting needs to be updated back to the source object, and this is done via each field object's Update method, like so:
$SPField1.Update()
$SPField2.Update()
$SPField3.Update()
$SPField4.Update()
Lastly, we can dispose of the website object instance:
$SPWeb.Dispose()
After making these changes, the list's NewForm look's like this:
These modifications do not affect the list's DisplayForm or EditForm, which still show all fields:
and

To show these fields in the NewForm again, just set their ShowInNewForm properties back to $false.  This method works for all custom columns that you add to the list.  Note that this method does not work for the system generated Created and Modified fields.

References

  • Thanks to Krishana Kumar in this posting for first showing AlsTechTips about this approach.
  • Using Get-Member, you can see many other column/Field parameters you can easily modify via PowerShell
  • This method does not work for hiding the system-generated Created and Modified fields.

Tuesday, July 12, 2016

SharePoint 2013 TIP: easy no-code method for obtaining Result Source IDs


  1. Launch Central Administration
  2. Navigate to: Farm Search Administration > Search Administration > Queries and Results > Result Sources.
  3. Click on the target result source listed.
  4. Copy the URL in the browser to NotePad.
  5. Look for that portion of the URL strong prefixed with sourceid=
  6. The string between the single quotes is the HTML-Encoded result source ID.
  7. Substituted a hyphen for each instance of %2D, and there you have it.

Notes

  • Use this test URL:
    • [site URL base]/_api/search/query?querytext='[your seaerch term'&sourceid='[result source ID]'
  • The default result source has GUID of: 00000000-0000-0000-0000-000000000000.

SharePoint 2013: User profile crawl failure: Access is denied

Problem

During routine system checking of development farm, found that when a full crawl was launched on user profile content source, crawl failed completely with the following error:
1 Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. 

Troubleshooting

  1. Check database roles and mapping: found that default content access account (e.g., spContent) added to database server login, with server role Public and mapped to all farm databases as public database role.
  2. Check My Site web application user policy: found that default content access account configured with Full Read.
  3. Check User Profile Service Application permissions: all appropriate service accounts added and configured with Full Control, including: farm service account (e.g., spFarm), application service account (e.g., spApp) and admin account (SharePoint Setup User Admin, e.g., spAdmin).  Compared with production and found that service service account (e.g., spService) also added her in production but not in development.  Added service service account to UPA permissions with Full Control.  Then retried UP content source crawl: still complete failure.
  4. Check User Profile Service Application Administrators: found farm (spFarm), SharePoint Setup User Admin (spAdmin) and my own administrator account configured with full control.  Compared with production and found content crawl account (spContent) missing: on production, this account configured with Retrieve People Data for Search Crawlers permission.  In development, added this account to UPA Administrators and configured with Retrieve... permission.  Then retried crawl: this time, crawl continued to completion.

Solution

  • Among other possibilities, be sure to check that the default content crawl account has been configured with the Retrieve People Data for Search Crawlers permission in the UPA Administrators dialog.

References

  • It's been awhile since I engaged in routine deployment efforts and so initially missed the significance of configuring a crawl account with the Retrieve People Data for Search Crawlers permission.  Also the crawl log error that was entered is misleading: it directs attention to verifying permissions in the web application, not the service application.

Monday, July 11, 2016

SharePoint 2013: cannot sort Content Search webpart results by document Title property

Problem

A customer employed a Content Search webpart on an organizational home page to present search results involving documents having specific properties.  The Content Search webpart had been deployed and configured by a designer no longer available.  The webpart was displaying the appropriate documents, but these documents, as listed in the webpart, were not being sorted by document title.  These documents, and most documents throughout the site collection presented differences between their filenames and document titles - the two are hardly ever the same.  The customer needed these document results to be sorted by the document title.  However, the documents were being listed and sorted by filename.  The customer had repeatedly tried to change the search criteria herself to implement sorting by document title, but had not been successful.  The customer then opened a support ticket.

Troubleshooting

  1. Check webpart: verified that it is a standard OOTB Content Search webpart.
  2. Check Content Search query: tested the query on development instance and verified that the query generates the expected document listing output, just not sorted per customer needs.
  3. Check Content Search query sorting: configured using Filename property Descending.
  4. Configure Title property for sorting: could not find Title property in Sort by dropdown.
  5. Verify Title property is being crawled: found the Title property among properties being crawled.
  6. Verify Title property Sort configuration: found that the Title property Sortable parameter was set to No.
    1. Action: Set the Sortable property to Yes - active, and then clicked OK.
  7. Verify Title property appears in query sorting: found the property properly listed in the Sort by dropdown.
    1. Action: launched a full crawl.  Waited for crawl to complete.
  8. Configure Title property for sorting: set sorting by the Title property Ascending, and then applied changes: documents listed in the Content Search web part now sorted by Title ascending.

Solution

  • If unable to find this or other property in the Sort by dropdown, on the SORTING tab of the Build Your Query dialog, verify that the propery's Sortable parameter has been set appropriately.  It's this managed property parameter that determined whether the property will appear listed for sorting purposes.

References

  • The Content Search webpart employs the Build Your Query dialog tool to enable creating and modifying of content search queries.
  • To find a specific crawled property and check its configuration, first go: Central Administration > Search Administration > Queries and Results > Search Schema > Crawled Properties tab > [enter "Title" and then click the arrow].  
  • Curiously, after setting the Sortable parameter of the Title property to Yes-active , I found the property immediately appearing in the Sort by dropdown.  Moreover, I also found that I could configure sorting using this property.  However, the results would only appear descending, regardless of whether I selected the Sort by to be Ascending or Descending.  Once I performed a full crawl and tested this again, the displayed results responded to changes here as expected.