Basic troubleshooting
1. Make sure all DotNetPanel applications (DNP Portal, DNP Enterprise Server and DNP Servers) are of the same version.
2. Make sure all DNP applications have been upgraded to the latest DNP release.
3. Make sure you are able to open all DotNetPanel applications (DNP Portal, DNP Enterprise Server and DNP Servers) URLs in web browser.
4. Make sure DNP Servers are able to manage systems where they deployed. For this, for example, from the panel open Windows Services (Configuration > Servers > Server name > Windows Services).
5. Those error messages can contain useful information for troubleshooting:
a. Error message (if exists) with stack trace from DotNetPanel Audit Log (Serveradmin account home page -> Audit Log).
b. Errors and warnings from DotNetPanel event log in the Windows Event Viewer (on Exchange mailbox server or server which manage mailbox server remotely/on SharePoint Server with DNP SharePoint module deployed/on CRM Server with DNP CRM module deployed).
To increase level of DotNetPanel event log you need to go to C:\DotNetPanel\Server (or another directory if you install DNP components to non-default paths) end edit web.config file with notepad. Find <add name="Log" value="1"/> and set value to 3. After this please check that DotNetPanel event log is set to "Override events as needed".
*Please note: The most important is first error or warning appeared in this log during error reproduction.
Error 0x80005000 while create site collection
It as AD access error.
1. Please check DNP Server account permissions on local computer, AD and SharePoint root web application.
http://help.dotnetpanel.com/DotNetPanel%20Hosted%20SharePoint%20Solution/DNP%20Hosted%20SharePoint%20Solution%20Installation%20Tasks.aspx#Section1
2. Please check that DNP Server on your SharePoint Server is in "AD mode"
http://help.dotnetpanel.com/DotNetPanel%20Hosted%20SharePoint%20Solution/DNP%20Hosted%20SharePoint%20Solution%20Installation%20Tasks.aspx#Section2
Common problems with SharePoint search
1. NTLM authentication is not set on root application level.
2. If site was created as SSL or not. In case you open site created as SSL as http - search will not work, and vice versa (issue from your next question)
3. In case of SSL - WSS server need to trust CA that issue SSL cert.
4. In case of SSL - site collection URL should be correct and no SSL warnings should appear when you open site collection. In DNP Hosted SharePoint solution, where wildcard certificate used for root Web Application it should be like this - https://customer.hosterdomain.com where *.hosterdomain.com is wildcard certificate used for root Web Application.
5. Ensure that root Web Application is bounded to "all unassigned" or at least correct internal IP address and WSS server itself resolve its name to correct local address. For example in case WSS server is WSS01 and its internal address is 10.0.0.1, when you try to ping WSS01 from WSS01 box it should resolve to 10.0.0.1 and root Web Application should be bounded to bounded to "all unassigned" or at least 10.0.0.1.
6. In case WSS server is located behind NAT - search service try to use Site Collection name that resolved to one of external NAT's address. A lot of NATs can not handle this and do not forward IP packet to internal WSS IP. I suspect you have exactly this issue. You can try to fix your NAT or edit local hosts file on WSS server like:
10.1.1.1 team.customer.com
Or
10.1.1.1 customer.hosterdomain.com
7. Good test is try to open SharePoint site collection from SharePoint server itself. In case you can open it, but can not login - please check this http://support.microsoft.com/kb/896861/en-us Microsoft article.