Search This Blog

Tuesday, October 4, 2016

SharePoint does not search custom column

There was a small issue with SharePoint 2010 that in advanced search could not find documents with specific string in custom column.  We have a custom column Prof

../_layouts/OSSSearchResults.aspx?k=(scope:"Documents")  Prof=QA

In the list we can see that this field has that value and we can even filter on it.

So somthing is wrong with search?

Indeed if we search as ../_layouts/OSSSearchResults.aspx?k=(scope:"Documents")  owsProf=QA

it finds ok the item. S the problem is ac tually in managed property. It is either does not exisit or not mapped correctly to crawled property. To fix that goto Central Admin, SEarch service administration - Metadata Property Mappings and add missing property - Prof - then map to crawled property  ows_Prof(text)




SharePoint get and set columns with powershell

http://social.technet.microsoft.com/wiki/contents/articles/20831.sharepoint-a-complete-guide-to-getting-and-setting-fields-using-powershell.aspx#Set_and_Get_a_Text_Field

Monday, October 3, 2016

Microsoft ATA 1.7 upgrade fails

https://social.technet.microsoft.com/Forums/en-US/c0af68af-15c4-497c-8366-0628fe9105be/17-upgrade-fails-error-code-0x80070643?forum=mata

Solution (System.Security.Cryptography.CryptographicException:   Bad Length)

1. From the C:\Program Files\Microsoft Advanced Threat Analytics\Center\MongoDB\bin directory execute:
Mongo ATA
2. Paste the above “Mongo Script” that relevant to the error, for example:

CenterThumbprint=
db.SystemProfile.find({_t:"CenterSystemProfile"}).toArray()[0]
.Configuration.SecretManagerConfiguration.CertificateThumbprint;
db.SystemProfile.update({_t:"CenterSystemProfile"},
{$set:{"Configuration.ManagementClientConfiguration.ServerCertificateThumbprint":
CenterThumbprint}})


rerun upgrade

Thursday, September 15, 2016

Avaya and Exchange UM integration - something you need to know about Exchange



https://johanveldhuis.nl/exchange-um-accepteerd-geen-oproepen-meer-na-de-upgrade-naar-sp1/

https://social.technet.microsoft.com/Forums/exchange/en-US/a156daf9-7793-43b6-bbb6-3bd282d5cf7a/um-2013-does-not-answer-calls?forum=exchangesvrunifiedmessaging

Exchange Server runs two unified messaging services, umservice.exe (on Exchange 2010 and Exchange Server 2013 Mailbox Servers) or Microsoft.Exchange.UM.CallRouter.exe (on Exchange Server 2013 Client Access Servers) that listens on TCP 5060 and UMWorkerProcess.exe (both versions of Exchange Server) that listens on TCP 5065 or TCP 5067. The correct process for connecting to Exchange Server unified messaging is to connect to TCP port 5060 and get back a SIP Redirect to either port TCP 5065 or TCP 5067. The reason for the redirect is that Exchange Server starts listening on 5065 and after a week starts a second process listening on 5067 and once the process on 5065 has finished all its call handling it will stop the process listening on 5065. This way Exchange Server manages the process, memory management, etc. without needing to restart the process if it goes bad – it just starts a process on the other port from the current process and directs all new calls at the new process.