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)
Search This Blog
Tuesday, October 4, 2016
SharePoint get and set columns with powershell
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:
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 22, 2016
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.
Thursday, September 8, 2016
Subscribe to:
Posts (Atom)