Getting VMware View 3.1 running on Windows 7 SP1 in Parallels 6 on OSX Lion.

I was able to install the VMware View 3.1 client by connecting to the SSL View host at work, but when connecting to my desktops (after providing credentials), I got this error:

The View Connection Server authentication failed. The SSL initialization while connecting to server ‘https://(elided):443′ failed.

I noodled around with the usual suspects for network, SSL and tunneling settings:

• Firewall settings.
• Network settings.
• Antivirus settings.
• Parallels general settings (esp. Network and security)

No successes.

Finally I tried to change the Parallels Tools and set the Network mode from Shared Network to Bridged Network -> Ethernet.

Here’s a relevant Parallels KB article (yes, the version is out of date).

Worked like a charm.

• Details of Hack focuses on the actual details of the hack, including some e-mails exchanged with the hacker in question and some initial steps at remediation (both on my personal blog and this one).
• Rebuilding covers the majority of the work I did to rebuild, recover and secure both of these blogs post-hack.
• Recovered is just a sum-up. The fact that I added more stuff to Rebuilding, above, after posting Recovered should be of little consequence. Pay no attention to the man behind the curtain.

Only time will tell whether I have enough utz to keep updating this blog too as work provides me more information/insights/knowledge.

• In an isolated dev environment set up to enable Kerberos in SharePoint 2007 and SQL Server 2005, a single VM Server for the DC, one for the SQL Server and one for the SharePoint Web Front End, developers were unable to create custom databases in the SQL Server instance and use SQL Server local logins to connect to those databases with ODBC.
• Tests with generic UDL shortcuts (ODBC) failed with the error “Login failed for user “<username>”. The user is not associated with a trusted SQL Server connection.” upon clicking “Test Connection” button.

Carried out the following tests:

• Made sure we had the right password for the testing account. If needed, can change passwords this way.
• Made sure that the Database instance was set to support both SQL Server and Windows Integrated Authentication (this is what the majority of Google hits for this problem suggested).
• Checked some Registry settings:
  • LoginMode
• Made sure that SQL @@servername was correct (select @@servername executed as a query helps with this. Google can help provide more details).
• Checked SQL Logs for more information (found Error 18452 after each connection failure)
• The term “trusted connection” suggested that the issue might be with Kerberos even though we were using local accounts, so I also checked for the “Integrated Security” connection string value per discussion here.
• Finally went through the UDL shortcut configuration again, and found an interesting phenomenon. If you click the “Test Connection” button you get the generic trusted connection error. But, if you click the drop-down list for selecting the database you want to connect to, you get a very applicable error message.

The fix for this problem is to go back into the SQL Server Management Studio, edit the properties for the local user and first enable “Enforce Password Policy” for the user, THEN uncheck all of the options including “Enforce password expiration” AND “User must change password at next login”.

We have HP xw4600 Workstations with pretty high performance specs. 8 GB RAM, 1.2 TB HDD, Quad core 2.5 GHz Intel Core2 CPUs, Windows 7.

For the longest time we would get intermittent BSODs (blue screens of death), either while actively working or while the computer sat idle, with the following error message:

***Hardware Malfunction
Call your hardware vendor for support
NMI: Parity Check/Memory Parity Error

***The system has halted***

We did days of diagnostics, running the HP system diagnostics over and over again, looking at the Web for information that might help, looking for updated drivers, etc.

In the end, it came down to some conflict my system was having with Forefront Client Security. I replaced it with a copy of AVG Antivirus and now the system seems stable. I let it idle over the weekend to be sure and will keep an eye on it anyhow, but I am hoping, knock on wood, that the system is finally stable.

The short summary is that using a Microsoft whitepaper (linked to below), I could get Windows XP SP2 workstations to work properly opening an Explorer View to a SharePoint 2007 farm’s document library, I had a bunch of other problems to surmount when trying to get a Windows Server 2003 SP2 system to do the same. The rest of this post is about other methods for troubleshooting and fixing the situation.

Situation:

• SharePoint Server in EXTDOMAIN (our extranet domain) named sharepointbi.mycompany.net (MOSS 2007 running on Windows Server 2003 x64 SP2)
• SQL Server cluster node (SQL Server 2005 active node running on Windows Server 2003 x64 SP2 – named: sqlolap.mycompany.net)  running an ETL job finishes up by attempting to use xcopy from a filesystem share to a document library at http://sharepointbi.mycompany.net/site/dl/ (UNC path: \\sharepointbi.mycompany.net\site\dl\) using WebDAV.
• Various Windows XP SP2 workstations (e.g. named: mcy20m68f.mycompany.com – yes, in another domain) also mapped a drive or file copy operation via WebDEV to \\sharepointbi.mycompany.net\site\dl\
• xcopy/share mapping operations from the SQL Server seemingly worked for a couple of days and then consistently failed.
• xcopy/share mapping operations from the Windows XP SP2 worksations mostly worked.

Troubleshooting:

We spent a day or so under the mistaken impression that the network protocol at issue was SMB. It’s not. When you’re talking about SharePoint, you’re talking about WebDAV or possibly Web Folders (but only if you install an add-on) for file system-like operations against its resources. Generally when you’re using a UNC path that uses a SharePoint-hosted resource as a file system-like resource, your computer is accessing SharePoint via WebDAV.

It took some time to establish that the Understanding and Troubleshooting SharePoint Explorer View whitepaper DOES apply to SharePoint 2007 (the publication date sort of indicated it might not), but I guess the WebDAV infrastructure of the SharePoint product line hasn’t changed substantially since SharePoint 2003. I don’t know for sure, but this seems like a logical guess.

After I went through that whitepaper and applied it to both the problem SQL Server we were working with and the recalcitrant (not always connecting immediately on the first try) workstations, I got all the workstations working properly. In some cases, what in the whitepaper looks like an optional setting – e.g. like putting the target SharePoint server in your Trusted Sites in your Internet Options to avoid getting prompted for login – was vital. Some machines seem not to automatically provide credentials during the WebDAV connection and the connection fails.

This still left the SQL Cluster node (Windows Server 2003 SP2 machine), which was still consistently failing. The final fix ended up being a mixture of things found and not found in the whitepaper I linked to above:

Server settings (one time settings for the box):

• Hosts file entry.
  In our case the SharePoint Farm and our network configuration channels and redirects regular traffic going through a front end load balancer through SSL. The load balancer chooses among several web front ends for incoming traffic. WebDAV doesn’t support any port other than port 80. The hosts file entry points the client machine (sqlolap.mycompany.net) to a particular web front end server in the SharePoint farm directly, via its accessible back-end port, avoiding the SSL redirect and the load balancing.
  Example: The back-end NIC for your chosen WFE in the farm has an IP address of 10.3.1.100 and the URL to the resource you’re trying to map is http://sharepointbi.mycompany.net/site/dl/. Your hosts file entry on the client machine attempting the WebDAV connection should look like this:
  10.3.1.100     sharepointbi.mycompany.net
• Verify that the Web Client service is running properly on the client system. It should have an Automatic startup and be Started in the Services display for the server.
  Also note that if you are running Windows Server 2008, you’ll also need to install the Desktop Experience Feature on your system or the Web Client service won’t be available for you to start or stop.
• Change the order of Network Providers for the system so that the “Web Client Network” provider is at the top instead of the bottom of the list.
  This was necessary because for some reason the server that was acting as the client in our setup would have its SMB negotiations fail and simply wouldn’t fail down to the Web Client Network provider like it was supposed to. Microsoft support and I were not able to determine why. It’s an open question whether this makes anything else break and my Microsoft resources are looking into it. I’ll update here if anything’s found.
  Anyhow, you make this change by opening up the client’s Network Connections dialogue in Control Panel. From there, go to the Advanced drop down menu and choose Advanced Settings… This pops up a dialogue where you can choose the Provider Order tab. There you can move the Web Client Network provider up to the top of the Network Providers list.

User Profile settings (Internet Options settings that carry with each user profile):

• Disable the proxy or set an exception to proxying for the target SharePoint Server (though we had less consistent luck with this).
• Add the target SharePoint Server to the Trusted Sites group in the Security Tab. Uncheck the “Require server verification (https:) for all sites in this zone” checkbox since you won’t be using port 443. During troubleshooting I put two entries in here:
  • http://sharepointbi.mycompany.net
  • sharepointbi.mycompany.net
• Check the Security level for the Trusted sites zone. You can set it to Default Level (which s/b Low for this content zone), which should work, but the seminal setting in the whole thing was the User Authentication setting at the end of Security Settings for the Trusted zone, which should be “Automatic logon with the current username and password”.

Next steps:

• Verify that your WebDAV connection is working. You should be able to do this with any windows operation that allows you to open the SharePoint document library as a filesystem resource. My favorite methods were:
  • Windows Explorer
    Just open up Windows Explorer and sock the SharePoint document library as a UNC path typed into the Location bar. (e.g. \\sharepointbi.mycompany.net\site\dl\)
    I found that even with the site in Trusted sites and Authentication set to always logon with current credentials, the Server 2003 client prompted me for manual entry of credentials anyway.
  • net use
    Use net use to map a drive with the UNC path (\\sharepointbi.mycompany.net\site\dl\).
    e.g.: net use * \\sharepointbi.mycompany.net\site\dl\
    Then remove same by drive letter (e.g. if the letter your system assigns is Z:):
    net use z: /delete
  • xcopy
    Use xcopy to copy a file from the UNC path (\\sharepointbi.mycompany.net\site\dl\) to some temporary folder. Verify that the file copies and you know WebDAV is working.
    e.g. xcopy \\sharepointbi.mycompany.net\site\dl\test.txt .
• Make sure that changing the Network Provider order isn’t doing any long term damage. Will update this if I get word from my Microsoft support folks.
• Test the inclusion of the Web Folders add-on (KB 907306) that Microsoft suggested on that client machine.

Here are the salient notes and facts about troubleshooting and achieving the ultimate goal (having Kerberos working with our systems).

• The most detail-oriented troubleshooting involves use of Microsoft’s NetMon (apparently the new version is pretty sweet) or Wireshark. We used Wireshark. This captures all the network traffic your workstation or server is exposed to during the recording period. You can filter the network transactions according to protocol, port, originating and destination IP addresses, etc. It also lets you inspect HTTP packets and other protocols it knows how to decode.
• If you are following the TCP stream (right-click on an HTTP  TCP packet in the capture and choose “Follow TCP Stream”), what you are looking for are GET requests that include an Authentication or WWW-Authenticate header field. Further, in there, what you are looking for is a string that starts with “Negotiate: ” and is then followed with a semi-random string. If the string is a Kerberos string, it starts with the letter “Y”, and can be quite long (~1 page or window full of gibberish). That’s the packet where your client presents a Kerberos ticket to the server. Follow up troubleshooting from that point. If the server responds with a 401 (unauthorized), your client will start degrading the authentication, which means Kerberos is screwed up somehow for you. Other Negotiate strings can start with “T|RM” or “o”, etc.
• You’ll also find Kerbtray helpful. This is part of the Windows Server 2003 Resource Kit. Run it in the systray of the client/server you’re troubleshooting. This will tell you if the machine it’s running on (and the user account that’s current logged in) have any Kerberos tickets, and when they were granted. Unfortunately it doesn’t look like Kerbtray will show any tickets granted to any other accounts running via “Run As…” in your login session.
• Other tools that are useful: Active Directory Users and Computers (part of normal Windows 2003 administrative tools under program files for any Admin account you log into) – You’ll need sufficient rights to see the servicePrincipalName property on various accounts (service accounts, application pool IDs).
• Another: ADSI Edit, which is part of the Windows Server 2003 SP2 support tools, is a customized LDAP Browser which gives you another window into the AD and another way to look at service accounts. This is another way of getting to similar information that you can find in ADUC, above.
• Another: SetSPN, which you use on the command line to add SPNs to accounts and to list SPNs already assigned to accounts. Depending on how well or inconsistently your AD reflects your LDAP organization (of the same data), you may find you need to find the Distinguished Path (the string with all the CN= and OU= values) for your AD Object with a “setspn -l” command on the object and then find the object in LDAP with ADSI Edit based on the path output by “setspn -l”.
• Kerberos related activity in the IIS logs appear to be timestamped in UTC. Don’t freak out if that’s several hours in advance of your local timezone. Kerberos probably isn’t screwed up due to timesync errors.
• Another way of looking for Kerberos-authenticated sessions is by looking at your (Web Front End) server’s Security Events Log. Open it via the Event Viewer. You are looking for a Success event, number 540, where the User is the user you’re troubleshooting. If the session achieved a valid Kerberos login, the Logon Process in the Event Description should read “Kerberos” and the Authentication Package should also read “Kerberos”. Logon Type is probably 3. If the Logon Process and Authentication Package read “Negotiate” or “NTLM” instead, your Kerberos is probably not working. If you have more than one Web Front End that are load balanced, be sure to check all of them for the user you’re troubleshooting.
• Proper Kerberos setup is almost all about the SPN. If you are lost about what SPNs you should be using, you might want to look at the Excel worksheet that SharePoint from Scratch published (down as I write this post up – drop me a note and I can send you the one I did up myself).
• If your domain’s FQDN is domain.local and you have a web application with an FQDN in that domain of host.subdomain.domain.local, your SPNs may have to include:
  - HTTP/host.subdomain.domain.local
  - HTTP/host.subdomain
  - HTTP/host
  all set to the service account that runs the Application Pool for that web application. What’s at issue is whether the “host.subdomain” or simply the “host” SPN is the proper one in that context for the short SPN name. I’ll update this if I have more information.
• The service descriptor listed if you use “setspn -l” on a service account is sometimes capitalized and sometimes lower-case (i.e. the SPN is sometimes listed as “http/host.subdomain.domain.local” and sometimese as “HTTP/host.subdomain.domain.local”). It depends on how the SPN was created, and who created it. According to Microsoft IIS support, the capitalization does not matter, but the convention is to capitalize it.
• You may find SPNs missing for application servers. If you do a “setspn -l” on a server object in the active directory (e.g. “setspn -l domain\host$”) and you get no SPNs returned, you probably neet to use “setspn -a” on that object (with a domain admin account running the command) to add the FQDN and short name for the host to its SPNs. You may have to set these SPNs from a command shell running on the server in question. For a host whose FQDN in the domain is host.domain.local, the two SPNs that should exist for that host are:
  - HOST/host.domain.local (command would be “setspn -a HOST/host.domain.local domain\host$”)
  - HOST/host (command would be “setspn -a HOST/host domain\host$”)
• The overall, final fix for almost all of our problems actually laid in applying the hotfix that installs the Microsoft Office Servers Infrastructure Update: July 15, 2008. This was weird especially because the seminal guide for implementing Kerberos on SharePoint (on TechNet) seems to indicate that you only need this hotfix if you plan to implement Kerberos with your SSP internal farm transactions.

Anyhow, if you have a web application with no site at the root managed path, adding a best bet to a site collection on some other managed path will pop up a window that says,

Error

The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.

The way to fix it is to create a site collection at the root managed path. Or probably upgrade to SP1.

Yes, I know the error is completely unhelpful. I found it so as well.

Now he wants the full toolbar and the View Selector drop-down.

Well and good, but how?

I see two possible approaches.

1. If the list is small and customizations relatively few, note the URL of the list and any customizations, save off content. Delete list. Start over, re-upload the content after the recreation. Don’t forget to create initially with whatever end of the URL you want for the list, then rename after the list is created at that URL.
2. If the list is larger or customizations greater, do some fiddling with SharePoint Designer 2007, Datasheet View and XSLT.
3. There is no third thing.

I don’t see any good ways of doing this in the UI only without just recreating the list entirely.

Anyone else have any good ideas?

Here’s how to create that full functional pipeline WITHOUT SharePoint Designer (to create the people search results page where SharePoint’s expecting it to be), thank you very much.

This may help you with defining additional site scopes and dedicated landing pages for their results too, assuming you also have a Search Center deployed.

WARNING: If you do this, you will end up renaming the Home tab in your horizontal nav bar to whatever your top level site’s name is, and the only way to get it back (short of SharePoint Designer) will be to disable the Office SharePoint Server Publishing Infrastructure feature at the Site Collection level. This may be okay with you and your users or not, depending on how much tweaking you intend to do through that feature/interface.

1. (Optional) Create Site Collection with Team Site top level site. Do this if you just want to proof it out. Otherwise, if you already have a site collection you want to do this with, start at steps 2 or 3 below, depending on what you’re starting with.
   1. Do this operation in the Application Management tab of Central Administration.
   2. Under the SharePoint Site Management section, click the “Create site collection” link and follow the prompts from there.
2. (Optional) Create Search Center Subsite (w/o Tabs). This assumes you haven’t already got a Search Center subsite or site collection to work with.
   1. Do this operation within the top level site you just created. This may work in other contexts too, but I have not tested those.
   2. Choose the “Search Center” option under the Enterprise tab when choosing a site definition.
   3. I chose not to list the subsite in the Quick Launch, but I did choose to list it in horizontal navigation and to use the parent site’s horizontal navigation. If you choose different settings, know these may affect your site collection’s behavior.
3. Assign Search Center as Search Center target for top level site.
   1. Do this operation within the top level site you just created.
   2. Go to Site Actions -> Site Settings, then click Search settings under the Site Collection Administration section all the way to the right.
   3. Provide the path starting with the end of the FQDN to the search center’s simple URL (e.g. if the top level site iat http://example.com/sites/tls/sc, then input /sites/tls/sc into the textbox.
   4. Click OK button.
4. NOTE: If you’re starting with the same assumptions I am and you test the People search scope now, you should receive a 404 error, regardless of whether your crawls are working. This indicates the lack of a proper results web part page for the results to go into.
5. Enable Office SharePoint Server Publishing Infrastructure Feature and Office SharePoint Search Web Parts Feature (not entirely sure this is required) on Site Collection.  (Enabling the first feature here will change your Home Tab in horizontal navigation to the Top Level site name.)
   1. From top level site, choose Site Actions -> Site Settings.
   2. In Site Collection Administration section, click the “Site collection features” link.
   3. Click “Activate” button to right of Office SharePoint Server Publishing Infrastructure Feature item.
   4. Click “Activate” button to right of Office SharePoint Server Search Web Parts Feature item.
6. (Optional) If you don’t want the potentially confusing changes to the Site Actions menu to impact the top level site, immediately disable the Office SharePoint Server Publishing Feature on the top level site.
   1. In the top level site, go to Site Actions->Site Settings->Modify All Site Settings.
   2. Under the Site Administration (NOT the Site Collection Administration) section, click the “Site Features” link.
   3. Click the “Deactivate” button to the right of the Office SharePoint Server Publishing Feature item.
7. (Optional) Enable Office SharePoint Server Publishing Feature on Search Center Site. You may not have to do this, as it may be auto-enabled when the Site Collection Features are enabled. An easy way to tell whether this feature is activated on a site or subsite is by looking at the Site Actions menu. If it’s just 2 or 3 items (depending on the page you access it from): Create, sometimes Edit Page, and Site Settings, then you know this feature is not enabled. If instead it’s a huge menu with multiple fly-out submenus, then you know the feature is already enabled on that site.
   1. Go to Search Center site.
   2. Click Site Actions -> Site Settings and in Site Administration section, click Site features link.
   3. Click “Activate” button to right of Office SharePoint Server Publishing Feature.
8. Create new page in Search Center for People Search Results.
   1. Click Site Actions -> Create Page
   2. Create a page called peoplesearchresults.aspx. Save it where the dialogue lets you save it. Probably Pages/*.aspx.
   3. Choose the “(Welcome Page) Blank Web Part Page” Page Layout.
   4. Click “Create” button.
9. Add appropriate People Search result web parts to new page.
   1. On created page, if not already in page edit mode, choose Site Actions -> Edit Page
   2. Add appropriate web parts, put them on the page in appropriate places and modify their web part settings to suit. I chose:
      • Header: People Search Box
      • Center: Search Statistics, Search Paging [1], Search High Confidence Results, People Search Core Results, Search Paging [2]
      • Center Right: Search Best Bets
   3. Click Publish button to finalize edits to web part page.
10. Edit Search Scopes on Site Collection.
    1. Go to your top level site.
    2. Choose Site Actions -> Site Settings.
    3. In the Site Collection Administration section, click “Search scopes” link.
11. Copy “People” Search Scope (default) to a copy for the Site Collection.
    1. Use drop-down menu on “People” Search Scope and choose “Make Copy”
12. Edit the “Copy of People” Search Scope to set proper results page URL and change name (can’t just be “People” as that name’s already taken).
    1. Use drop-down menu on Copy of People and choose “Edit Properties”.
    2. Click “Change scope settings” link on next page.
    3. Change Title to something descriptive that isn’t “People”.
    4. Enable or Disable the Display groups you want for this scope.
    5. Specify the target results page you just created. Start relative url at the search center’s root. So if, for example, the search center is at http://example.com/sites/tls/sc/ and your results page ias at http://example.com/sites/tls/sc/Pages/peoplesearchresults.aspx, use the value “/Pages/peoplesearchresults.aspx” in the Target results page textbox.
    6. Click the “OK” button.
13. Remove default “People” Search Scope from Site’s selectable scopes.
    1. Go to the Search Scopes settings page in the top level site (Site Actions -> Site Settings -> Site Collection Administration -> Search Scopes)
    2. If you’re using default Display Groups, you should have “Search Dropdown” and “Advanced Search”
    3. For each display group click the hyperlinked name of the group in the grey bar, labelled “Display Group” (e.g. for Search Dropdown, click the hyperlinked Search Dropdown in the phrase “Display Group: Search Dropdown (3)” (or some other number) in the grey title bar just above the list of scopes active for that display group).
    4. In the Edit Scope Display group page, uncheck the Display checkbox to the left of the People scope name.
    5. Click the OK button.
    6. Repeat this for any other applicable Display Group you have in Search Scopes.
14. Let your crawls happen. The settings you made won’t be reflected in your sites until after the next crawl. If you have access to the SSP, you can reinitiate crawls to try to rush the process and make it happen immediately.
15. Retest. Hopefully you’re all hooked up now.
16. If everything is hooked up and you don’t want the publishing infrastructure and you want your Home tab back, you can now disable the Site Collection feature.
    1. Go to your top level site. Go to site settings (Site Actions -> Site Settings).
    2. Under the Site Collection Administration section, click the “Site collection features” link.
    3. Click the “Deactivate” button to the right of the Office SharePoint Server Publishing Infrastructure Feature.

If not, don’t come crying to me!

Actually, I’ll be happy to try to help, but keep in mind that I don’t have a lot of spare time.

Seems I need to change the site title or hack the navbar in a combination of SharePoint UI and SharePoint Designer (not my first choice).