Note: This update is required in order to install future SharePoint updates.
SharePoint Foundation: http://www.microsoft.com/en-us/download/details.aspx?id=36987
SharePoint Server: http://www.microsoft.com/en-US/download/details.aspx?id=36989
Project Server: http://www.microsoft.com/en-us/download/details.aspx?id=36988
Office Web Apps 2013: http://www.microsoft.com/en-us/download/details.aspx?id=36981
I often see talk about administrators disabling IPv6 for one reason or another. A lot of that comes down to “I don’t use it, so I don’t leave it enabled”. Always makes sense from an administrator perspective… except when it comes to IPv6.
Microsoft has made sure, since Windows Vista and Server 2008, that IPv6 was a first-class citizen in Windows. In fact, so first-class that Windows will leverage IPv6 before attempting to leverage IPv4. If there is an IPv6 path available, IPv6 will be used.
Microsoft has an FAQ on IPv6 which specifically states while they understand that some administrators do disable IPv6 in Windows, IPv6 is a mandatory part of Windows and do not test disabling IPv6 during the development and testing process for Windows (this means leave IPv6 enabled!).
SharePoint 2010 fully supports IPv6 in an IPv6-only or a mixed IPv4 and IPv6 environment. All supported editions of SQL Server for SharePoint 2010 also support IPv6. The only restriction with IPv6 for SharePoint is that you cannot browse directly to the IP address over the HTTP protocol (e.g. browsing to http://[fe80::bc95:be32:cc03:845b%2511] would not work) and all DNS records must be using quad-A (AAAA) records for IPv6 addressing. Any farm element that otherwise can take an IP address will accept an IPv6 address, given it is enclosed in brackets “[IPv6-Address]”.
The world is out of IPv4 address. It is time to start testing that IPv6 rollout!
Update: This has been completely resolved in the December 2011 CU.
====
EDIT: The behavior has changed in the August 2011 CU. After the second postback, the Administrator’s name will become unresolved and will force the administrator to resolve the name.
If you attempt to configure a second (or more) Project Server Web Access site via the UI, you may encounter this error with SP1 and the June CU:
![image[3]](http://sharepoint.nauplius.net/wp-content/uploads/2011/08/image3.png)
A work around is to delete the Administrator name, and simply retype it. For some reason, if you’re on the PWA creation page, and perform a postback (e.g. change Web Applications), there is an extra space prefixed to the Administrator name which causes the above error. You can easily test this by selecting one Web Application, then another, and finally another; you’ll encounter the above error.
With Project Server 2010, post Oct 2010 CU in a resource domain (where as your users are in a logon domain), issues arise while attempting to use Project Web Access’ “Manage Users” to add new users. If you attempt to add a new user from the logon domain, you receive the error:
The resource could not be saved due to the following reasons:
|
1 |
The NT account specified is invalid. Check the spelling of the user name, verify that a valid domain name was included, and check that a duplicate domain was not used. |
This is due to Project Server not having a record of the user in the Global Catalog. Project Server relies on the Display Name as well as the Pre-Windows 2000 logon name being present in the Global Catalog. In a one-way trust scenario, that Global Catalog entry is not available.
Workarounds include adding the user from the logon domain to the underlying SharePoint site Project Web Access is using (using Site Settings -> Site Permissions), or preferably, using Claims Based Authentication with the logon domain.