FAQs


Specific

Changing the Intermediate Repository Path

Before doing any changes to the publisher components, the new Repository folder has to have the following:

  • Read/Write permissions for the AspireUsers group or at least for the account(s) you are using to access the folder.
  • The Shared Path of the new folder.
  • The folder has to be accessible from the servers running the Aspire Distribution and the AspireBDCService.

Aspire SP2013 Publisher

For the Aspire SP2013 Publisher you only need to change the Repository Path on the publisher's configuration and click save.

AspireBDCService

  1. Go to IIS and look for the AspireBDCService site.
  2. Right click on the site and then click Explore.
  3. Look for the web.config file and open it.
  4. Under <appSettings> look for the "RepositoryPath" key and set the new path.
  5. Save it.

IIS should recycle the AppPool for the AspireBDCService automatically, but if it doesn't, then manually recycle it by selecting "Application Pools", then AspireBDCService and click on Recycle.

 

Working with multiple BDC Service Applications

Having more than one Business Data Connectivity Service Applications on the same SharePoint Server causes the Aspire SharePoint 2013 Publisher to fail when trying to create the new content source on the Search Service Application and link it to the corresponding BDC Model. Because of this issue the content source won't start crawling when the Notification Endpoint triggers it.

When a new BDCS is created its proxy has to be assigned to a Service Application Proxy Group. All BDCS proxies (and all the other Service Applications Proxies) that the admin creates will be assigned to the default Service Application Proxy Group unless it's changed. The proxy group is where the Aspire BDC Model is imported and where the Notification Endpoint gets the BDC url to create the content source. To get the proxy group the BDCS is loaded using the BDCS name on the endpoint parameters and ask for its proxy group, then the model is uploaded to that proxy group. The issue is that in that step the proxy group has multiple BDCS proxies assigned and there’s no way to tell it which one is needed, so it uses the default BDCS proxy (the first one created). After that the content source is created without the BDC url because, even though the BDCS proxy group name and the model name are sent as parameters, there are multiple BDCS proxies, the Proxy Group isn’t able to resolve the BDC url needed and it then returns nothing, leaving the content source with no BDC association.

To fix this we need to create a custom Proxy Group Association for each BDCS that we want to use to crawl batches from the Intermediate Repository. Each Service Application can have a custom Application Proxy Group association. So when having one custom Proxy Group Association for each BDCS, we can leave each Proxy Group with only one BDCS proxy (the one we need), and then when creating the BDC model and the content source, it will only have one BDCS and will be able to load and resolve everything without getting lost.

One of the symptoms of this issue was that on the content source configuration the BDC model checkbox wasn’t checked. This is still happening, but it doesn’t affect the fix because the content source does know the BDC url and starts crawling automatically (when the Notification Endpoint triggers it) and everything is indexed correctly.

 

Create a Custom Proxy Group for a Service Application

  1. Go to Central Administration -> Application Management -> Configure service application associations

2. On the view drop down, select Service Applications.

3. Now select the BDCS where you want to add the custom Proxy Group.

4. On the group of connections drop down, select custom.

 

5. Select the all the Service Applications you need except the other BDCS available on the server. Make sure you set the BDCS as default for this Proxy Group.

6. Save the custom proxy group by clicking Ok.

7. If everything works fine, you'll see the new group on the next screen.

 

 

 

Publishing to Https SharePoint 2013 server

If the SharePoint 2013 server where the Aspire Notification Service solution was deployed is using https, then the Notification Service will also be using said protocol. In this case Aspire needs to know the certificate needed to connect to the Notification Service. Follow these steps to register your certificate.

 

  1. Download the site certificate using your web browser.
  2. Open a new Command Prompt as an Administrator
  3. Run the following command: 

    keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>

     

    1. <AliasName>: an alias for your site certificate

    2. <certificate>: path to the certificate you want to register

    3. <KeystoreFile>: path to the keystore used by your Java installation. The default location is: %JAVA_HOME%\lib\security\cacerts.

    4. <Password>: password for the keystore. The default value is changeit.

  4. Check that your certificate is now registered: 

    keytool -list -keystore "%JAVA_HOME%/jre/lib/security/cacerts"

SharePoint 2013 AspireBDCService FAQ

See Aspire BDC Service FAQ page.

SharePoint 2013 Notification Service FAQ

See Notification Service FAQ page.

SharePoint 2013 Security Pre-Trimmer FAQ

See Security Pre-Trimmer FAQ page.



Known Issues


Microsoft recommends deactivating SMB1 from Windows servers

Problem

Due to a security issue observed with the protocol, Microsoft has recommended deactivating SMB1 from Windows servers.

This affects the SP2013 Publisher, which uses the JCIFS library to communicate with a file share. The JCIFS library only supports the SMB1 protocol; it does not support the SMB2 or SMB3 protocols currently. As a result, the SP2013 Publisher may be unable to communicate to a Windows file share (using protocol SMB2 or SMB3).

Solution

We are working on finding a solution for this scenario (SMB1 deactivated).

  • No labels