When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.
I aim to keep this post reasonably quick, because I’ve lost enough time to this issue already and I want to get some other posts written up soon, but this is one of those things that I should probably help raise awareness of. I foresee that this could become more of an issue in future if take-up for Native Boot from VHD solutions rises, or as people run demos from bootable removable media, etc.
A while back, I posted an article on building a SharePoint development environment in Hyper-V, which included a part on automating deployment of the host machine. Although we’ve now moved to VMware Workstation, we still use this approach for automating deployment of our standard Windows 7 builds, and this commentary is generally relevant to any Windows Deployment Services (WDS) deployment.
When I learned WDS and the Windows Automated Installation Kit (which were both quite new in Windows Server 2008 R2 at the time), I contented myself with getting ~90% of the way to a fully-automated build, as the additional effort to get from 90 to 100% (mostly re: drivers) wouldn’t have paid enough immediate dividends and we needed to start capitalising on some of the other wins of our new environment. As is often the case, we never got back to that remaining 10%, but it’s become more of an issue in recent months, as we’ve added a few Dell Latitude E6410 and Lenovo W520 laptops – both of which had network drivers that the Windows 7/Windows Server 2008 R2 boot images didn’t recognise. Unfortunately the TechNet guidance on adding drivers to boot images is unclear (to me anyway), so I’m contributing this quick post to attempt to clarify the problem that we had and the simple step-by-step solution.
A couple of months ago I was happily building a client’s SharePoint Server 2010 farm when I stumbled at Search. The Service Application provisioned fine, but when I pushed out topology changes I started to have problems. Later, these problems returned in different forms, but the root cause appears to have been consistent. In this post I will review the symptoms, the single fix and the reason why this issue emerged in this environment. I’ll also look at some unexpected permission changes that occur when new servers receive Search Service Instances.
In my last post I discussed how the Product Version Job timer job uses the Windows Installer Service to query the installed state of SharePoint 2010 servers and how the Manage Patch Status page in Central Administration displays this information. I also touched on my reservations about what we can infer from this data. In this post, I’m diving a bit deeper in to that question.
Continue reading “Testing Manage Patch Status”
Back in August, I stumbled across a new type of DCOM 10016 error in SharePoint 2010, caused by the Product Version Job timer job. When I found the error, I was primarily concerned with keeping my event logs clean. Since then, the inelegance of my original work-around and the incomplete picture I contented myself with at the time began to nag at me, but I only recently started digging deeper, prompted largely by the fact that this topic has generated more traffic to my blog in the last quarter than any other.
I finally tested the SharePoint Server 2010 December 2010 CU package over the last couple of nights. The good news is that it actually worked (I’ve had trouble with August and October) and it has a load of fixes, particularly for the User Profile Service Application. The bad news is that it’s known to require restarting the User Profile Synchronisation Service after it completes. In my tests, I also had to temporarily re-add the Farm account as Local Admin and reboot before re-starting the service, after running the installer and the Products Configuration Wizard. It failed when I just tried to temporarily add the Farm account as local admin and log off/on again, so the reboot before re-starting the service is likely to be necessary.
UPDATE 19/2/2011: I got a comment from Spencer Harbar today (below) noting that restarting the SPTimer service is sufficient after temporarily adding the farm account as local admin. The reboot isn’t necessary to acquire the new rights although in my test I did need to reboot after running the installer.
As promised in my SharePoint 2010 SEO Analysis with the IIS SEO Toolkit post, while the IIS.NET SEO Toolkit does an excellent job of generating an initial sitemap and providing a nice GUI for ad hoc updates, it does not offer any obvious scheduling mechanism to ensure that your sitemap stays current with the changing content in your CMS. Thankfully, my colleague Glyn Clough whipped up some PowerShell to produce a full sitemap for your web application based on Jie Li’s initial script, which was scoped at the root web. Running this as a Windows scheduled task will get you a very up-to-date sitemap for all sites in your web application with very little on-going maintenance. Nice one Glyn!
You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped.
Unfortunately I’ve found a problem with our development build, or rather, with SharePoint 2010. You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped. It appears that this is a known problem when provisioning this Service Application via the GUI. In fact, ours was created automatically as part of the Search Service Application creation process. At any rate, it doesn’t work in its current state in our environments, so it won’t actually collect any data.
To fix this just requires a couple of lines of PowerShell, courtesy of this article (to which I’ve added some clarification here).
I’ve previously reported problems with MAC duplication on Hyper-V host external network connections on Windows Server 2008 R2, which I’ve never fully resolved, although we have been successfully working around the issue as detailed in the first link above.
A couple of weeks ago I was working simultaneously on my Windows Server 2008 R2 laptop with Hyper-V (the same laptop build that’s been previously mentioned) and a Windows 7 x64 build that I was using for testing, when I noticed severe but intermittent network problems on both machines. After a fair amount of head scratching, I noticed that the two laptops had duplicated MAC addresses. Blatantly that shouldn’t happen, as the whole point of a MAC address is to provide uniqueness. The most perplexing issue was that the addresses conflicted across two different operating systems. However, it happened. Both wired adapters on the two machines had the MAC address 00-21-9B-DC-8E-0B. I uninstalled the wired adapter on the Windows 7 machine and scanned for new hardware. When the device reinstalled the problem went away. Continue reading “MAC duplication issues with captured VMs and WDS”