Hyper V virtual machine based Active Directory Domain

Bottomline:  Cannot run an Active Directory Domain on 169.254.x.x. address range!

I was recently trying to build a self-contained enterprise Windows environment on a powerful laptop to so I can take it with me for demo and work on the road.  I decided that it'd be a Windows 2012 Hyper V build with a VM as the Active Directory Domain Controller.  The host and additional VMs would join this domain.  So I installed Windows 2012 as the host on the laptop, and went on to create the first Windows 2012 VM as the Domain Controller.  Because I wanted the entire envrionment to be self-contained, I create a Hyper V Internal Virtual Network.  In both the DC VM and the host, I set the IP as static 169.254.1.x.  Installed ADDS and DNS, and Dcpromo'd the VM wihtout any problem.  From there, nothing worked. When I tried to join the host to the domain, I kept getting "The specified domain either does not exist or could not be contacted", and dcdiag.exe on the domain controller VM resulted in ._mstsc. could not be resolved to an IP address.  I noticed that the domain controller's own A record was missing but a manually added one kept getting deleted.  There are of course tons of information out there regarding these problems.  None worked for me.

After about one week of re-do ADDS, DNS, and dcpromo a dozen times, it finally hit me.  There was nothing wrong with DNS, which is usually the cause for all these problems.  The root problem, was in the IP addresses I used.  Since Hyper V automatically assigned the 169.254.x.x addresses in Internal Virtual Network, I did not used them.  This was the BIG mistaken.  169.254.x.x is special.  How special?  there are plenty of information out there about how special they are.  The point it, an AD domain cannot run properly on this because DNS gets completely confused.  The direct problem is that DNS cannot register the domain controller's own A record.  As soon as I changed the static IP of the domain controller and the host to 192.168.1.x, joining the domain immediately worked!

SharePoint search returns no results for most users

There are many reasons that SharePoint search doesn't return results. The simpler ones like the crawl failed, scope not crawled. If you are in a dev environment, it's likely that you suffer from sloppy use of service accounts. What I learned in a hard way recently is that in a new dev envrionment that I spun up, I was using the the farm admin account as the site collection admin on a site collection, and also use it as the crawl account. Using farm admin as the crawl account is not a best practice security wise but is actually done often to avoid many search related headaches. What I did not realize, is that using it as the site collection admin resulted in the search only returns results for this account in the site sollection. Logged in as any other accounts, search would return no results. In fact, the crawler account should only have explicit read permission in a site collection in order for the search results to return properly for any user. Even though the farm admin account has implicit permissions to any site collection, it must not have explicit site collection admin, site owner etc permissions on the site collection.

DCOM Component Properties grayed out in Windows 2008 R2

When you try to edit the Local Launch Permission of a DCOM component in Windows 2008 R2, the Properties window comes up with everything grayed out. Many have speculated that this is due to UAC or Group Policy. In fact it's the permission on the registry key of the classID of the component. Follow this article to change the permission on the registry key first, then the Properties window would have everything enabled.

http://blogs.msdn.com/b/emeadaxsupport/archive/2010/01/26/unable-to-edit-the-dcom-settings-for-iis-wamreg-admin-service-on-a-windows-server-2008-r2-when-trying-to-configure-kerberos-authentication-for-role-centers.aspx

Alert Me button missing from SharePoint 2010 ribbon

In SharePoint 2010 List or Library view, if the button Alert Me is missing on the ribbon (it should be next to the button "Email a link" in the middle), it's because Outgoing Email is not configured on the farm. You can still add alerts by selecting View Properties on a list item or document, then click Alert Me at the top.

Fix Mysterious 403 Forbidden error on SharePoint anonymous sites

While there're possibly many other permission related causes for the HTTP Status Code 403 Firbidden error on SharePoint anonymous sites, one in particular is very elusive and puzzling. If a page access terms from the metadata store, e.g. trying to get the Label of a TaxonomyFieldValue off a list item, it results in the 403 error.

The problem, as many people have pointed out, is that every site collection stores the metadata in its own hidden list called "TaxonomyHiddenList". It's at /Lists/TaxonomyHiddenList/allitems.aspx. This list by default has Anonymous access turned on:




However, something's missing but the UI's not showing. By simply click the OK button on the page above, it fixes the 403 erorr on pages that access the metadata in the site collection. So what does clicking the OK button actually do?

Behind the scene, the Anonymous Access of the list has only one permission: ViewListItems. When the OK button is clicked, it addes four more permissions to the permission set: OpenItems, ViewVersions, Open, UseClientIntegration. Apparently when reading TaxonomyFieldValue of a list item, some of these additional permissions are required.

In addition to manually click the OK button to fix the problem for a site collection, the following code snippet can fix the problem in the code:

SPBasePermissions newPer = SPBasePermissions.ViewListItems | SPBasePermissions.OpenItems | SPBasePermissions.ViewVersions | SPBasePermissions.Open | SPBasePermissions.UseClientIntegration;
SPList taxonomyHidden = rootweb.GetList("/sites/testSite/Lists/TaxonomyHiddenList");
taxonomyHidden.AnonymousPermMask64 = newPer;

Or better, get the Guest user's permissions on the site, and then add the additional permissions necessary:

SPBasePermissions currentPer = rootweb.RoleDefinitions.GetByType(SPRoleType.Guest).BasePermissions;
SPBasePermissions newPer = currentPer | SPBasePermissions.OpenItems | SPBasePermissions.ViewVersions | SPBasePermissions.Open | SPBasePermissions.UseClientIntegration;
SPList taxonomyHidden = rootweb.GetList("/sites/testSite/Lists/TaxonomyHiddenList");
taxonomyHidden.AnonymousPermMask64 = newPer;

Note that the code above uses the C# or operator (pipe) to assign mulitple permissions to the permission set. Run the code against the site collection in question and the 403 error would be fixed.

When the Ribbons block webpart picker...

On customized SharePoint pages, particularly Search Center pages, very often you end up with something like this when trying to add web parts to the page:

Notice that some of the webparts and categories are blocked by the Ribbon. If the one you want is blocked, first add any one that's clickable, then click on Edit Web Part in the newly added webpart, once the Edit Panel shows up, click on the Add a Web Part link again, now the webpart picker control shows below both the Ribbon bar and the header bar:

Nothing is being blocked anymore. Add the webpart(s) you desire, and delete the very first one that you added in previous step if it's not needed.

SharePoint anonymous access permission

Came across a good explanation on what exact permissions that SharePoint anonymous access has:

"In SharePoint, anonymous users' rights are determined by the Limited Access permission level. Limited Access is a special permission level that cannot be assigned to a user or group directly. The reason it exists is because if you have a library or subsite that has broken permissions inheritance, and you give a user/group access to only that library/subsite, in order to view its contents, the user/group must have some access to the root web. Otherwise the user/group will be unable to browse the library/subsite, even though they have rights there, because there are things in the root web that are needed to render the site or library. Therefore, when you give a group permissions only to a subsite or library that is breaking permissions inheritance, SharePoint will automatically give Limited Access to that group or user on the root web.

......If you want to see what rights Limited Access is composed of in your site, go to http://SERVER/_layouts/role.aspx and click on Limited Access. "

For more descriptions, see the original post
http://blogs.msdn.com/b/ecm/archive/2007/05/12/anonymous-users-forms-pages-and-the-lockdown-feature.aspx