When we are performing the Exchange Risk Assessment, one of things PFE love to check is how servers have been configured for IPv6. There have been numerous occasions where we have found servers whose admin has said that they have disabled IPv6, but when you look at the server it is not really disabled.
When we take a look at the Exchange server, the initial clue is that the network card’s TCP/IPv6 configuration looks like this, where IPv6 is unselected from the NIC.
There seems to be a belief that the simple act of clearing this ticky box disables IPv6 on the server. That is not the case. If we check the IP information we quickly see something like this:
ISATAP is part of the IPv6 protocol stack, so IPv6 is blatantly not disabled on this box…..
This is pretty frustrating, as this is a well documented process and a quick search using one’s favourite search engine quickly shows the steps required.
But let’s ask if IPv6 really should be disabled.
As Joseph Davies very eloquently said back in 2009 :
It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.
From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.
Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.
Exchange 2007, 2010, and Exchange 2013 support IPv6 with the details for each release contained within the documentation for the relevant product. Note that a dual stack configuration is required. In other words, for IPv6 to be supported IPv4 must also be enabled.
As discussed in KB 929852 the IPv6 configuration can be tuned or disabled via the registry. This is the DisabledComponents entry which is located here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Setting DisabledComponents to 0xff disables all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table
REG.exe query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents
One thing to note is the value specified above for DisabledComponents. It is 0xFF and not 0xFFFFFFFF. Why you may ask as 0xFFFFFFFF was what was documented, no?
Well yes it was, but it transpires that this adds a 5 second delay to the boot process. Way back with Vista 0xFF was the value used, and the documentation got out of alignment.
Unless there are specific reasons for disabling IPv6 please do not do it. Microsoft tests Exchange with both IPv4 and IPv6 enabled, i.e. the default configuration.
One common theme you will pick up from my blog posts, is that walking the most frequently trodden supported path is a good thing since issues are less likely to crop up. If an issue does occur, then the priority of a fix being quickly developed is very high. Corner cases will get less priority and this can cause the fix to be delayed.
Please follow the official documentation and KB articles to disable or optimise the IP stack.
If there is a business case for disabling IPv6 then do so using the above procedures. For example there is a case for disabling specific IPv6 features in an Exchange 2007 and 2013 coexistence environment as discussed in KB 2794253.
Cheers,
Rhoderick
TechEd Europe starts tomorrow! It is being held again in the beautiful and amazing city of Barcelona. You can be sure that TechEd will deliver lots of great product news and information.
You can use the catalog to review all of the sessions, but I wanted to call out a couple of particular interest.
The below sessions are being delivered by two of my Canadian colleagues, and internally within Microsoft these sessions have received great feedback, so please add them to your schedule and go get some great Lync content and advanced knowledge.
Connect and meet up with James and Matt, they are amazing guys and I’m very fortunate to have them as colleagues. Feel free to ask Matt why he loves Yamaha motorcycles, and ask James what makes him happy every day!
It seems like a long time since I was last in Barcelona, and it was. That would have been TechEd 2001, and the memorable UK breakout party still makes me smile.
Windows Update is a very important feature in the newer builds of the OS. If we think back to the NT 3.5/4.0 days the process to obtain updates was very different. Just to obtain a hotfix you needed to call in, provide credit card details and then obtain the update. How times have changed! And for the better!
This post is one of those Homer moments. When you realise for the last few years you been doing something somewhat silly!
We should all be familiar with the Windows update screen shown below:
In this example we have 15 Important updates to install:
And 1 Optional update:
Previously I would just click the Optional link as shown in the very first image above. I'd then tick the relevant updates as it then installs the optional update{s} and the important ones. Clicking the Important link would show those updates and I could never find a way to get back to the Optional ones as clicking Install, will immediately go off and install whatever is currently selected.
What I never realised, until last month, was that I can navigate between the two tabs. DOH!
In the left hand side of the window the Important and Optional updates are actually on separate tabs. This is the highlighted area in the below screenshot.
What this means is that you can toggle between then and select the appropriate updates. When you have chosen the appropriate update then you can click install.
How did I ever miss that……??
Last week after showing a client some of new features in Windows 10, they went off and upgraded a laptop to the preview from Windows 8.1. Initially all seemed to go well. That is until they tried to start up VMs on their SSD drive. At that point Mr Sad & Grumpy came to visit.
They were getting errors such as:
Looking at the details they saw Error 0x80070780. That is a fairly generic file system error. Doing a quick search provided no immediate clues. Please note the image above has been edited and redacted to remove some customer identifiable information.
Uh oh Shaggy, it's now troubleshooting time!
Creating a brand new VM, and then powering it on worked perfectly. There were no issues, and everything worked as expected. This proves that the hypervisor is loaded and is functioning correctly.
All of the original VMs continued to experience an error. We could see all of the files on disk, and superficially at least everything looked OK.
Now that we knew the hypervisor is OK, we went back and reviewed all of the Hyper-V event logs. That did not provide sufficient detail to fully understand the issue. Then we went back to the 0x80070780 error. What was making that error fire?
A mini Spanish inquisition then ensued! *
During a barrage of questions, we quickly discussed multiple topics. This ranged from SSD firmware issues, previous issues with the SSD drive and also what was the history with that particular laptop. Then there was an epiphany!
The clue is that the VMs were on an SSD. This was a small 64GB SSD, and you could image that 64 GB is not a lot of space in today’s world. To get more VMs onto this small SSD they had followed some of the unsupported 3rd party blog postings on the Internet to install the Windows Server 2012 R2 dedupe feature onto their Windows 8.1 machine.
This is not a supported scenario. When Windows 8.1 was upgraded to Windows 10, the installer does not expect to find the server dedupe feature so it was removed. All of the VMs that had been deduped were now inaccessible since Windows had no way to understand how to access them.
They were able to get access to the VMs by again following unsupported 3rd party blog posts to re-add the Windows 10 server dedupe bits.
In this case the admin got a fright, and managed to regain access to their VMs. However this should be used as a case in point where Microsoft support would not have been able to fully help since this is not a supported scenario.
Please note installing the Windows Server dedupe feature onto client builds is not supported.
* No cushions or comfy chairs were harmed during the making of this blog post.
After updating my Windows 8.1 machine to the Windows 10 preview, some of my VMs were no longer visible in the Hyper-V Manager. Prior to powering on some VMs, all of them were visible. After powering on, some VMs disappeared in the Hyper-V Manager console.
In the screen shot below, there should be 10 VMs displayed which have the prefix of “HA”.
Restarting the Virtual Machine management service made no difference. The VMs that were not displayed remain in that state, i.e. hidden.
But they are certainly there! Looking in PowerShell using Get-VM showed all the VMs:
They were still manageable via PowerShell.
Get-VM | Where {$_.State –eq “Running”}
If they were saved using PowerShell, then they appear in the GUI once again:
Get-VM | Where {$_.State –eq “Running”} | Save-VM
After they had been saved, simply refreshing the Hyper-V Manager made them all re-appear.
If the VMs were started up again, some of them would “stick” at the starting phase. This is highlighted in the screenshot blow.
Despite being marked with a status of “Starting” all VMs were all successfully started and were fully accessible. Refreshing the Hyper-V Manager would then cause VMs to again disappear.
OK – what is up with that VM? Why is it saying it is stuck starting, but the VM is actually running? Why is it not reporting it is in a happy place?
If we look at the VM Integration Services, there is a difference between a VM that is happy and the one that was stuck in starting phase. Note the highlighted areas below:
Get-VMIntegrationService –VMName “VMName”
Digging deeper, how does the VM heartbeat appear for these VMs?
Get-VM HA* | Select Name, Heartbeat
As indicated with the big red arrow, there is a bit of a difference…..
In the Windows 10 Preview, there is currently an issue if the VM heartbeat is reported as unknown. In this case, VMs do not appear in the Hyper-V Management console.
To workaround this issue, disable the heartbeat for these VMs. The following command will disable the heartbeat for VMs that have a status of “OKApplicationsUnknown”.
Get-VM | Where {$_.Heartbeat -eq "OkApplicationsUnknown"} | Disable-VMIntegrationService Heartbeat
After running the above command and refreshing the Hyper-V Manager the VMs are now visible! The naughty VM listed above is now in the running state and all is good!
Please remember that this is the initial preview of Windows 10, and that this article was written specifically for the preview.
Six months ago, we discussed that Office 2010 SP1 support was drawing to a close. This means that you now need to have Office 2010 SP2 deployed on all machines as the end of Office 2010 SP1 support is the 14th of October 2014.
The Microsoft support lifecycle site has the above details.
One thing to note here! Since I am focussed on messaging, the main thingy in the Office stack that I work on is Outlook. But note that there is not an Outlook 2010 service pack. This is the OFFICE 2010 service pack. Why is this important? Well this means assessing the impact of updating all of the installed Office 2010 bits and ensuring compatibility with your various applications and services. This is worth mentioning as it can be no small task to do so in a large enterprise environment, and those customer will have been planning this install for months!
While we are discussing Outlook 2010 specifically here, the same holds true for all products covered with the Microsoft support lifecycle. Please sign up for the Microsoft Support Lifecycle Quarterly Update Newsletterto stay abreast of supportability dates and ensure you get the support you deserve!
Generally the Exchange external Autodiscover DNS entity is configured as a regular A record. Sometimes a service record (SRV) is used instead. Since I have the habit of forgetting the syntax of quickly querying for the SRV record, this is one of those shared bookmark posts!
Nslookup is the tool of choice here! It's documentation can be found on TechNet.
There are two ways to run nslookup – interactive and noninteractive. Noninteractive is good when you know that you only want to query a single piece of data. Let’s take a peek at an example of each. We will check for the _autodiscover SRV record in the Tailspintoys.ca domain. The record points to a host called autod.tailspintoys.ca. The full format of this record is:
_autodiscover._tcp.tailspintoys.ca
For more reading on SRV records, take a peek at this article. And for Autodiscover in general please review this post.
Open a cmd prompt and run
nslookup -q=srv _autodiscover._tcp.tailspintoys.ca
You should see the below output. Note that the svr hostname will be the Autodiscover target.
In this example we launched Nslookup in noninteractive mode. The query type is set to SRV and then we checked for the _autodiscover._tcp.tailspintoys.ca record.
Open a cmd prompt and run:
In this example we launched Nslookup in interactive mode, so we can interact with it. The query type is set to SRV and then we checked for the _autodiscover._tcp.tailspintoys.ca record.
For reference purposes, the steps to add a Autodiscover SRV record will be something like the below. They are intended to be general so please follow any specific notes or items for the DNS registrar you are using!
In your DNS zone editor ad a SRV record with the following information:
Service _autodiscover
_autodiscover
Protocol _tcp
_tcp
Name Enter one of the following values:
Enter @ if your registered domain is your cloud-based domain. For example, if your registered domain is contoso.com and your cloud-based domain is contoso.com, enter @.
@
Enter the subdomain name if your cloud-based domain is a subdomain of your registered domain. For example, if your registered domain is contoso.com, but your cloud-based domain is the subdomain test.contoso.com, enter test.
test
Priority 10 (or as per your design)
10 (or as per your design)
Weight 10 (or as per your design)
Port 443
443
Target server.contoso.com (in the example above this was autod.tailspintoys.ca)
server.contoso.com (in the example above this was autod.tailspintoys.ca)
TTL Verify that an appropriate TTL is selected, 1 hour is a common default. (If you are approaching a migration, this should be decremented to allow for quicker cutover)
In addition to the SRV record pointing us to the correct location, we also have to ensure that there is a valid certificate installed which is published to the Internet. This could be something as simple as a NAT rule with the appropriate firewall rule for TCP 443 or it could involve TMG or a load balancer's APM.
The choice as they say - is yours!!
Depending upon the version of the sync solution that you are using to replicate directory data from on-premises Active Directory to Office 365 there are different commands that you will need to use.
We can see a listing of the DirSync versions on the TechNet wiki. And for AAD Sync, the version listings are on MSDN.
In September 2014 the Microsoft Azure AD Sync tool was released. This changed how manual sync requests are issued.
To perform a manual update we now use the DirectorySyncClientCmd.exe tool. The Delta and Initial parameters are added to the command to specify the relevant task.
This tool is located in:
C:\Program Files\Microsoft Azure AD Sync\Bin
The steps to migrate from DirSync to AAD Sync are listed here.
With build 6862 the PowerShell module has moved. The location for this module is now:
C:\program Files\Windows Azure Active Directory Sync\DirSync\ImportModules,ps1
To allow us to execute the Start-OnlineCoexistenceSync cmdlet we can either:
In the older builds of DirSync, we would use the DirSyncConfigShell.psc1 that was located in:
C:\Program Files\Windows Azure Directory Sync
or
C:\Program Files\Microsoft Online Directory Sync