Playing around with the RTM version of SharePoint Foundation 2013 today I noticed that when I stood up one farm, I got the search service but in a second one, where I felt fairly confident that I followed the same process, I did not. I have to admit that this entire situation to me was pretttttttty confusing.
Holistically speaking regarding the provisioned service applications, on server X I had all the service application I expected, however on server Y all I see is application load balancing and the security token service application. So whatever I go and try to create the search service application, however it is not being offered for instantiation. All I am seeing is app management, bcs, and secure store services. So not only was it not provisioned, I don’t even know how the hell to get it within the farm.
Navigating to PS, I attempted to use the cmdlets that I would normally use. SpSearchService isn’t there because it’s foundation and not SSE, and when I try to use the SPEnterpriseSearchServiceApplication it complains that I am running foundation. This equates to a big WTF? Furthermore, this problem extended to the State Service.
The only way to fix this within the current version is using farm configuration wizard, which will pump out the Search Administration Web Server for Search Service Application, Search Service Application, and WSS_UsageApplication. What a PITA.
Just want to the app?
Download here: http://spsecurityscanner.codeplex.com
I recently was at a client doing an audit on the SharePoint environment, and the question of how to do continual scanning on the site for possible system/ web service / and list WebForm exposure. Mimicking and automating this behavior is no big deal, since you are essentially just dispatching requests to various static URLs. The SPList object SPFormCollections can be exposed through the SPList.Forms property, and via web services rather than using the Forms web service you are sorta relegated learning on the SPList content type methods to get access to all customized forms. The SPWeb related ones are better to keep in a mutable file that can be managed.
So da da da! Here is a simple SharePoint security scanner. The composition of the application is actually pretty straightforward; it’s only about three forms. To abstract SharePoint explicit reference requirements the OM and web service assemblies are dynamically loaded at runtime so that SharePoint references are only required when doing OM connection types. Web service ones it shouldn’t really matter.
There are about three steps to get it going:
Start the application:
Click Open Connection:
And choose the connection type, and credential specifications:
When done hit connect, and you will return to the main form. Fill in whether you want to iterate SPList objects:
You can manage the web related urls, since the SPFormCollections are automated, through the Manage Web Inclusion List:
Scan the site, then you can view the results:
So it’s not very fancy, but gets the job done. Have hacky SharePoint fun!