Romania Networking Team Blog

Web client does not use stored credentials when using Basic Authentication

2013-04-30T09:22:00Z

if you wondered why you always get a Credential Prompt when connecting to a SharePoint Site using Basic Authentication, here is the explanation why.

consider the following scenario:

On a Windows 7 Client you map a Network Drive to a SharePoint site using the assistant:

you will get the first credential Prompt after click on [Finish], which is expected.

even though you checked [Remember my Credentials], you will get prompted again for Credentials after you logged of from

your Computer or you restarted your computer and accessing the already mapped drive to this SharePoint Site.

This is by design !!

Because Basic Authentication is the least secure way to authenticate in the World wide web, this is a security Feature

In one of the next Windows Versions, Basic Authentication will be depreciated and not available anymore.

It is better to choose one of the following methods:

- ADFS 2.0

- SSO

- Certificate Based

- Windows Integrated

cheers

Jonny

List of currently available hotfixes for the WebDAV Service in Windows 7 SP1 & Windows 8

2013-01-10T15:39:00Z

Hi all,

This Blog Post lists the hotfixes that are currently available for users who are using the WebDAV Feature on Windows 7 SP1 & Windows 8 -based computers to access there

SharePoint Servers. From my experience, most of the Described Problems in over 90% of the posts are fixed with Hotfixes from the following KB Articles:

Windows 8

Slow performance when you connect to a WebDAV shared folder in Windows 8 or Window Server 2012

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2782826

Webclnt.dll

Windows 7 SP1

You cannot open or save Office 2010 documents on a WebDAV file server on a computer that is running Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2727994/en-US

Mrxdav.sys

Cache files are not deleted on a WebDAV client computer that is running Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2790804

Webclnt.dll

Connection to a DAV server cannot established on a computer that is running Windows 7 SP1

http://support.microsoft.com/kb/2801244

Davclnt.dll

You do not receive an error message when you try to copy an email message that contains invalid characters from Outlook to SharePoint in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2691785/en-US

shell32.dll

I will update this Blog on a regularly base and suggested to install the latest Versions of the involved components before you take hours & hours of troubleshooting.

If the Problem still appears after you installed these fixes, than go ahead with troubleshooting or involve Microsoft support to help you!

Additional 1

I recommend you to also update the Networking components, you will find the List in the following KB Article which is also updated on a on a regularly base:

List of currently available hotfixes for the File Services technologies in Windows Server 2008 and in Windows Server 2008 R2

http://support.microsoft.com/kb/2473205/EN-US

Additional 2

You also can use the following Link to update the Windows 7 SP1 Client with all (incl. WebDAV) available Hotfixes post SP1 by installing the hotfix rollup:

An enterprise hotfix rollup is available for Windows 7 SP1 and Windows Server 2008 R2 SP1

http://support.microsoft.com/kb/2775511/en-US

I hope I could save you a lot of time of troubleshooting

Jonny

List of currently available hotfixes for the Offline Files Feature in Windows 8 and Windows 7 SP1

2013-01-10T15:30:00Z

Last update: 15.05.2013

Hi all,

This Blog Post lists the hotfixes that are currently available for users who have installed the Offline Files Feature on Windows 8 and Windows 7-based computers.

From my experience, most of the Described Problems in over 90% of the posts are fixed with Hotfixes from the following KB Articles.

Also please read the KB Articles in order to not miss any Registry Settings which are possibly needed or check for Script Samples.

The mentioned Binary's are only the important ones, please see also the complete List of Binary's listed in the KB Articles in order to see the differences, if you see that for example in 2 different Articles have the same binary's, you should install both because of the other in those Fixes included Components.

Here starts the List:

Windows 8:

High CPU utilization by the Wmiprvse.exe process on a client computer that is running Windows 8

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2810203

Cscui.dll

Windows 7 SP1:

The Folder Redirection policy does not work if a previous user sets a redirected folder to an offline mode in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2610379/en-US

Cscobj.dll

DFS network path goes offline in Windows 7 or Windows Server 2008 R2 when Transparent Caching Group Policy setting is enabled

http://support.microsoft.com/kb/2831206

Cscsvc.dll; csc.sys

Home folder is not mapped to a client computer when multiple users are logged on to a computer that is running Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2715922/en-US

Profprov.dll

Folder Redirection policy is not applied to a network share after you update a Group Policy in Windows 7 SP1 or Windows Server 2008 R2 SP1

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2799904

shell32.dll

I will update this Blog on a regularly base and suggested to install the latest Versions of the involved components before you take hours & hours of troubleshooting.

If the Problem still appears after you installed these fixes, than go ahead with troubleshooting or involve Microsoft support to help you!

Additional:

I recommend you to also update the Networking components, you will find the List in the following KB Article which is also updated on a on a regularly base:

List of currently available hotfixes for the File Services technologies in Windows Server 2008 and in Windows Server 2008 R2

http://support.microsoft.com/kb/2473205/EN-US

I hope I could save you a lot of time of troubleshooting

Jonny

Offline Shares change to Offline preventing Users to change/save open document from non Offline Shares without any Warning

2012-04-06T10:33:08Z

Hi, Jonny here and I am going to talk about the Transition to slow Link and why this is done seamless without any pop up Warning

When you have still open Documents from not offline available shares. The quick answer is, this is by design. If you wonder why, please keep on reading

I will explain it.

Consider the following Scenario:

You map a share and in this share you have Directory’s as follows:

Directory 1; 2; 4; 5 are not offline available

Directory 3 is offline available

You are connecting to the CorpNet via UMTS and VPN. While connected to the CorpNet you open a File which is located in

DIR 1 and you make changes to the File. While working with the File, the slow Link Detection considers the Link as ready to

Change to offline Mode due to low latency.

What happens now is, the DIR3 is accessible while the other DIR's are not available anymore. When you want to save the Changes to your open file

and get the following Pop ups:

You have the possibility to save the File Local.

Why is that, because when I decide for myself to work Offline by clicking [Work Offline] in the Windows Explorer, I will get a Warning like:

The Reason for this behavior is as follows:

Slow Link Mode is an Offline Files Feature and the transition to offline Mode due to slow Link is done by the Service account. The mechanism does not check if there are files open

From Directory’s which are not offline available because when the transition to slow Link mode is done, we expect the share which is registered in the cache with \\Server\Share\Jonny\

and only DIR3_offline_available is pinned to be offline available and the File was opened from the Cache and not directly from the Share.

But why do you get a Prompt when clicking on [Work Offline]?

By clicking on [Work Offline] you force the Share to be offline manually with the User which is logged on. The Windows Explorer checks for open Files and will prompt you to make a choice!

The Slow Link Mode mechanism is not used in this case.

I hope this sheds some Light into this subject.

Cheers

Jonny

“PING: transmit failed. General failure” and general outgoing connections on a NLB Cluster node

2012-01-23T10:32:00Z

I recently came across two similar scenarios involving NLB Cluster nodes where outgoing connections failed.

In the first one we had an NLB Cluster with 2 nodes, each node having one interface on which only the NLB (common) IP address was configured. The issue was that, even if the cluster was reachable from other machines - responds to PING, TCP connections etc, the nodes were unable to connect to any other machine. In his case, the nodes could not connect to a network share, but we later found out that they were actually unable to send out any IP packet. ICMP, DNS, SMB, nothing worked. All connection attempts terminated very fast with various errors.

When we tried to ping other machines, we received the error:

“PING: transmit failed. General failure”

This is in fact expected and it functions according to the design. The NLB IP Address is added to the network interface using the “SkipAsSource” flag, meaning it cannot be used as a source IP Address for outgoing connections.

More on “SkipAsSource” - http://support.microsoft.com/kb/2386184

You are also prompted that you will not be able to establish outgoing connections when you are configuring the cluster:

The solution in this case was to add a dedicated (unique) IP address on each of the nodes, to be used as a source IP address for the outgoing connections.

One can do this from the NLB Manager -> Select Host -> Host Properties -> Host Parameters -> Add Dedicated IP Address.

In the second scenario we had 2 interfaces on each node, from which one was configured with a dedicated (unique) IP, and the other, used for NLB, was configured with only the NLB (common) IP address.

In this case, we were unable to establish connections from the nodes to the Cluster IP Address. As before, the Cluster was reachable from other machines; this time we could also reach other machines because we had the dedicated IP Addresses on the other Interfaces, but we were unable to connect to the cluster IP Address.

We had the same error when pinging the Cluster IP Address:

What happened: when deciding how to send (in this example - ) the PING packet, TCPIP first chooses the interface on which it will send the Packet, according to the routing table. Obviously, to reach the NLB IP, we would go out through the NLB interface. But, on this interface we don’t have an IP address useable as a source IP for outgoing connections (Remember, the NLB IP has the “SkipAsSource” flag set.)

Therefore, we fail in sending out packets to the NLB IP Address, even if the address is a local one.

More on Source IP address selection: http://blogs.technet.com/b/networking/archive/2009/04/25/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx

The solution here was the same as in the first case: add a dedicated (unique) IP address on the NLB interfaces.

Upload of large files (> 100 MB) via WebDAV on Windows 7 is failing when upload takes longer than 30 Minutes

2012-01-21T13:27:00Z

Scenario:

Jonny again, this Time I want to tell you a little bit about the Web Client Service (WebDAV) on Windows 7 SP1. Consider the following Scenario:
You are working from your Home Office connected to your ISP for Internet access. You are finished with your work and want to upload your Data to a
IIS 7.5 WebDav Share over HTTP(S) that your co workers can access the Data. You start the upload, you see the Progress Bar moving very quick to
the end and stay's there. After 30 minutes you receive the following Error :

Error: 0x80070079 The semaphore timeout period has expired

What happend? You check if the Internet connection is broken => nop, it is not
then you check if your connection from the PC to the Router is broken => nop, it is not

in Short: you check every possible cause but everything works fine and you are going crazy, but don't give up

the Problem is:

1. The Progress Bar moves very fast but the upload takes long time is due to Web Client is copying the file to the WebDAV TFS (WebDAV Temp Files) Store on the Client
and uploads it from there to the IIS WebDAV Share.

2. the bigger issue is that you click on repeat and after 30 minutes the same error occurs

the Cause is the Timeout for upload over Web Client is by default 30 minutes.

The Solution is to modify the following Registry Key in minutes to a higher Timeout:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRxDAV\Parameters
DWORD: FsCtlRequestTimeoutInSec

Ok, but now your coworker is working in teh Home office just like you, he want's to download the file from the IIS Server to his HDD on Windows 7 SP1

using the Web Client and also get's Errors like:

"Cannot Copy FileName: Cannot read from the source file or disk"

Copy Folder

An unexpected error is keeping you from copying the folder. If you continue to receive this error, you can use the error code to search for help with this problem.

Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved.

Try again Cancel

Oh men, how to fix this?

again, don't give up, the cause is a 50 MB download Limit on Windows 7 SP1 for Web Client and yes, we have a Registry Key where we can raise the Limit, Huhu :)

Just Modify the following Registry Entry in bytes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
DWORD: FileSizeLimitInBytes
Default is 50000000 bytes.

Now you are ready to upldoad and download bigger Files by using the WebDAV (Web Client Service) over HTTP(S)

Hope this helps

by Jonny

Why can't I ping my DHCPv6 Server?

2011-11-01T14:37:50Z

If you configured a DHCPv6 Server and the respective scope of IPv6 addresses. The clients are able to get an IPv6 address from the DHCPv6 server, but still the Clients are unable to ping the DHCPv6 Server in a successful way.
The DHCPv6 server is a Windows Server 2008 R2 based server.

ICMPv6 echo request in the local subnet fails with "PING: transmit failed. general failure"

This is expected. You have published the route on the server, which ends up as a Prefix Information option in the Router
Advertisement (RA) message with the Autonomous (A) flag set, indicating to the receiver that they should configure a stateless address based on the advertised prefix.

Therefore you are getting both stateless (public + temporary) and stateful (DHCPv6-allocated) addresses.

To prevent the stateless behavior, the router advertising the RA must clear the A flag in the Prefix Information option. The result will be a local subnet route and a stateful
(DHCPv6-allocated) address.

The problem with DHCPv6-assigned IPv6 addresses is that the DHCPv6 client does not also create a local subnet route for the prefx in the address. This is the role of the local subnet
routers.

Solution for this:

You need routers that can advertise the local subnet prefix with the A flag cleared, otherwise the DHCPv6 client will generate a stateless address and get a DHCPv6-assigned
address.

Using Offline Files on DFS Shares / all shares are going offline!

2011-01-24T16:17:00Z

What happend? You only made 1 DFS Target available offline, but all of the shares are offline when Slow Link is detected or the File Server is down.

Consider the following Scenario:

You configured a DFS Root in the \\Domain Contoso.com\Public

the Targets are:

Offline on the File Server \\Server_1;
Nosync on the File Server \\Server_2;
Sales on the File Server \\Server_3;

on the Vista / Windows 7 Clients you map the Drives as follows:

O:\Offline
N:\Nosync
S:\Sales

You make available offline the mapped drive O:\Offline

Now it happends, the Server \\Server_1 is down and the share offline is not accessible anymore

You will notice that all the mapped drives O;N;S are offline and not accessible anymore even though the other Servers are reachable via Ping

Here is the Reason:

The Offline Files feature does not distinguish DFS paths from UNC paths. This can cause the Vista / Windows 7 client to interpret the entire namespace as unavailable if a target is down when a Vista / Windows 7 client attempts to access it. For example, if \\Contoso.com\Public is a domain-based root with several root targets and numerous links, the Offline Files feature interprets this namespace as a single server named \\Contoso.com. If a client is accessing or attempts to access the target Offline in the \\Contoso.com\Public namespace, and the target is unavailable, the Vista / Windows 7 client interprets the entire namespace as unavailable and will attempt to open a user’s locally cached files (if they exist). The Vista / Windows 7 client cannot access any target (in our example: Nosync & Sales & Offline) in the namespace until the target comes back online. The Vista / Windows 7 client will check every 2 minutes to detect whether the target has come back online.

What to do to avoid this:

- Use the NetBIOS Name or FQDN of the Target Server for mapping the Offline Files Share

Arguments against disabling IPv6

2010-11-24T08:37:00Z

Hello! Dorian again with a blog article regarding IPv6.

The main background of writing this blog post is that until now best practice says “If you aren’t using it, disable it!” or our customers see lots of talk on message boards saying “Your Internet is slow? Disable IPv6! That’ll fix it!” and they develop the wrong idea about what IPv6 does and how it works.

This way we’ve noticed that a lot of customers ask how they can disable IPv6 in the supported way. The answer to this Question is in KB929852 that shows ways to disable certain components, how to alter the in prefix policies or how to deactivate everything except the IPv6 loopback interface.

How to disable certain Internet Protocol version 6 (IPv6) components in Windows Vista, Windows 7 and Windows Server 2008
http://support.microsoft.com/kb/929852

Even if this is the “supported” way to deactivate IPv6, Microsoft does not recommend that customers disable IPv6 if they are not planning to use it in the network. Please take into considerations that you “might” face issues or problems and that at some time after you open a Service Request we might need to request you to (re)enable IPv6 just to see if the problems were caused by the deactivation itself.

Some of this possible issues are:

When IPV6 is disabled via registry hacks in http://support.microsoft.com/kb/929852 or via unbinding in the NIC bindings, UDP 389 ceases to respond. This behavior is a known behavior and is referenced briefly in kb 816103.

Be aware that the LDAP test over UDP may not work against domain controllers that are running Windows Server 2008. One reason for this can be that you have disabled IPv6 on the Domain Controller. To re-enable IPv6, set the value discussed in the article below to the default of "0".

What occurs here is that a check is performed to see what the maximum response can be and it calls into an API specific to IPv6 for the result. The return is a null value as the protocol is not enabled. There is a possibility that there may be an additional check included to see if more than one IP protocol is bound to the adapter, however our official stance on IPv6 is not to disable it on 2008 or later platforms.

Exchange 2007 recommended disabling IPv6 to fix an issue with Outlook Anywhere. The Exchange 2007 limitation was fixed in Exchange 2010. The customers that disabled IPV6 and later upgraded to Exchange 2010, then ran into issues because IPV6 was disabled. http://support.microsoft.com/kb/977623/EN-US

Disabling IPv6 costs you money. There is no default GPO that allows IPv6 to be disabled. Depending on how it is disabled, re-enabling it can be challenging. We have several customers that heard this and decided to disable IPv6 in Vista, anyway. When Windows 7 rolled around, the same customers wanted to deploy DirectAccess, and began complaining how hard it was to find all the machines that had v6 disabled and get it re-enabled on those clients. Disabling v6 increased their management costs for very little benefit, and re-enabling IPv6 cost them again. Our goal is to help customers lower TCO, not raise it.

IPv6 is required by the Common Engineering Criteria. All Microsoft products for the enterprise should support IPv6. Future versions of our products may require it.

Additional Refferences:

The IPv6 Blog
http://blogs.technet.com/b/ipv6/

Disabling IPv6 Doesn't Help (By Sean Siler)
http://blogs.technet.com/b/ipv6/archive/2007/11/08/disabling-ipv6-doesn-t-help.aspx

The Argument against Disabling IPv6
http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx

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 like Windows7 or Windows Server 2008 R2, 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. Additionally the P2P APIs require IPv6, and those are public APIs. If IPv6 is disabled, programs that use the P2P APIs will break. This could impact application compatibility for third party apps.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled.

Let’s think even further about the transition to IPv6 and the benefits of being IPv6 ready:

Customers CANNOT learn IPv6 in a weekend. They need time to roll this out, in a slow phased migration. This is what Microsoft has recommended from the beginning. If customers wait until the day their ISP says “Sorry, we’re out of IPv4 addresses !” to start thinking about IPv6, they are in deep trouble. Right now according to the NRO Less than 10% of IPv4 Addresses Remain Unallocated.

More info regarding this here:
Less than 10% of IPv4 Addresses Remain Unallocated, says Number Resource Organization
http://www.nro.net/media/less-than-10-percent-ipv4-addresses-remain-unallocated.html

As of 30 September 2010 according to ARIN Stats we got only around 5% of the IPv4 Address Space left. Don’t fall behind, start your IPv6 planning now !

IPv6 Learning Roadmap now available (by Joe Davies)
http://blogs.technet.com/b/ipv6/archive/2010/11/02/ipv6-learning-roadmap-now-available.aspx

The IPv6 Learning Roadmap provides an organized and sequential list of Web and print resources that you can use to build your understanding of IPv6, starting with prerequisites and then adding level 100 (introductory), level 200 (intermediate), and level 300 (advanced) knowledge.

As a final conclusion:
IPv6 was designed to have no impact to the customer environment in production. No double queries, no DNS entries, no tunneling through the firewall, no performance degradation. If you feel like you have seen any of these and can provide data for troubleshooting, please feel free to open an incident with Microsoft so that we can discuss it.

Slow Link Detection for Offline Files in Windows Vista SP2 & Windows 7

2010-09-15T07:22:00Z

How is it measured?

Offline Files measures the speed of a link based on the packet latency between the client and the target server.

This is reported by the network driver and TCP stack and is then used to compute the throughput to the server for comparison

with the configured throughput and/or latency policy configuration.

Windows Vista SP2 further improves this feature by taking into account both the inbound and outbound traffic.

Out of those two, values it takes the smaller of them when determining if a transition to slow link is needed.

You can configure the Slow Link in the GPO: Configure slow-link mode

On client computers running Windows 7 or Windows Server 2008 R2,

a shared folder automatically transitions to the slow-link mode if the round-trip latency of the network is greater than 80 milliseconds, or as configured by this policy.

After transitioning a folder to the slow-link mode, Offline Files synchronizes the user's files in the background at regular intervals, or as configured by the 'Configure Background Sync' policy.

While in slow-link mode, Windows periodically (every 2 Minutes) checks the connection to the folder and brings the folder back online if network speeds improve.

If you do not configure this policy setting, computers running Windows Vista or Windows Server 2008 will not transition a shared folder to the slow-link mode.

Computers running Windows 7 or Windows Server 2008 R2 will use the default latency value of 80 milliseconds when transitioning a folder to the slow-link mode.

To prevent computers running Windows 7 or Windows Server 2008 R2 from using the slow-link mode, disable this policy.