WDS 4.0 and DFS

Question

Hi,

 

We installed "WDS 4.0 Preview" on two of our fileservers and indexed all local files. Those two fileserver are part of our DFS Namespace and hold the same data (syncroniced via DFSR).

 

When we try search from am Desktop pc (also with "WDS4 Preview" installed) it is not possible to use the remote index when we connect via our DFS Namespace!

It only works if we search via \\Servername\Share but NOT \\Dfsroot\Dfsnamespace\Share

 

Is it possible to make this work?

 

Wolfgang

 

 

Answer 1

Hi,

This is an unknown issue.

Please let me know, on which OS the Clients and servers are. I will followup internally.

 

Thanks

Answer 2

Hello Thomas,

I have the same problem as Wolfgang!


My Scenario:
- Client (XP):                    Windows XP Professional SP2 ENG x86 with "Windows Search 4 Preview" (WS4) installed
- Dataserver (NAS):          Windows Server 2003 Standard SP2 ENG x86 with WS4 installed
- Domain Controller (DC):  Windows Server 2003 Enterprise SP2 ENG x86
All of them are members of the same Active Directory Domain (native 2003 mode) and have the latest updates installed.

First I created a DFS-Root on the DC and linked some DFS-Shares to the shares on my NAS (btw: FRS is not activated between my dataservers).
Then I created two "Network Drives" (ND) on the XP:
- the first ND points to the DFS-Share (\\mydomain.local\dfs\share1)
- the seccond one points directly to the NAS-Share (\\nasserver\share1)

In the "Windows Search Result"-Window I add those two ND as new search locations.
- If I search via the first ND (DFS-Share), I get no search-results but the message "Nothing found in 'NetworkDrive:\Folder' for query 'xyz'."
- If I search via the second ND (NAS-Share), I get all appropriate results in just a few seconds (which is quiet nice by the way )

As far as I understand, WS4 asks for the Remote-Index of the NAS through the "Terminal Services"-Service (which has to be activated as said in the WS4-System Requirements).
Unfortunately the DFS-Share is based only on a virtual UNC-Domain-Path (\\mydomain.local\dfs\share1) and therefore no TS-Service is available.
It seems, that WS4 is not aware of the fact, that behind this virtual DFS-Share is of course a physical Windows Server (with an activated TS-Service!).

Is there an workaround for this issue? Will it be fixed in the final WS4-Release or is it locked down by design?
I should mention, that Microsoft pushes the DFS-Technology since Windows 2000 which is in use in many companies nowadays...


thank you for your support,
Andreas

Answer 3

Hi Andreas, Hi Wolfgang,

I did a followup on this.I am afraid to answer, but you are right.

 

There is currently no DFS integration in the WS 4.0 product. Remote queries need to be directed to a specific machine (\\server\share). I skip the technical details here, why the DFS search is currently not possible and what would be needed.

 

The WS4 design is nearly completed (as supposed above) and this feature will not make it into the final version WS 4.0.

Though, your voice is heard and we will consider the feature for the next Windows Search version.

 

Regards

Thomas

 

Answer 4

 

Hi Andreas, Hi Wolfgang,

we want to learn more about your site and environment in more detail - please can you provide an email account that we can contact you directly in this regard?
Please send your email to [e-mail]

 

Regards

Thomas

Answer 5

Are there any news regarding the WDS and DFS shares ?

 

Or does anyone know another product that can index files on a DFS share so that they can be searched for XP clients ?

 

Answer 6

Hi Thomas,

 

Are the any news on WDS and DFS support ?

 

Or are there any other ways to index files on a dfs share and search them from a XP client - i.e. Windows 2008 or WSS ?

 

Regards

 

Morten

Answer 7

Hi,

 

I´have just tried this with Windows 7 - It still does not WORK !!!!

It is also impossible to to add DFS shares to libraries! - (seems to be the same cause...)

Hopefully this will be fixed !

 

Wolfgang

Answer 8

Unfortunately, it's now 2009, and Windows Search is still useless with DFS shares.

DFS are great to hide complex server structures with multiple storage servers, but the lack of support for them in Windows Search are forcing us to make a decision to either lose the benefits of DFS, or lose the benefits of Windows Search...

 

Config: Windows Unified Data Storage Server 2003 R2, Windows Vista and Windows 7 clients.

 

Any chances of DFS support in some Windows Search 4.1 ?

 

Answer 9

One more company here...

We also use DFS and would like to deploy Windows Search after trying both it and Google desktop...but the lack of support for DFS shares in windows search server-indexing is a show-stopper.  We'll be looking at a Google appliance if we have to...

Ideally what we want is a group policy to be able to 'publish' DFS paths to user's desktop search interfaces, using the path names they're familiar with already (\\company.com\department\engineering\ for example).  And for the indexes to be maintained on the fileservers. 

Some users have experimented with direct indexing of the DFS paths on their machines, but we're afraid if we let all users locally index the contents of the file servers it will kill their performance...not to mention use client CPU and network resources unnecessarily...

Answer 10

Same problem here.

Not support for DFS will be a show stopper for upcoming use of libraries in Windows 7.

Anybody know if DFS service in Windows 2008 R2 supports libraries in Windows 7?

But a BIG problem.

Answer 11

BTW WDS 4.0 is remote query PC to PC:

http://www.microsoft.com/windows/products/winfamily/desktopsearch/choose/windowssearch4/business.mspx

Windows Search 4.0 adds the following features to help you find just what you're looking for:

• Remote query (PC to PC): Search for and access shared files stored on remote PCs that are running Windows Search 4.0. Once the PC where data is shared finishes indexing, search for and quickly access any documents saved to those locations the same way you search for files on your own PC.

DFS is not a peer of PC to PC.

However, in my case with libraries in Windows 7 and Windows Search Service on Windows Server 2008 the problem is still true. DFS needs to be indexed and available for libraries to work efficiently. It adds to the problem that Libraries will be a superconcept in the UI when Windows 7 comes out.

I will try and install SSE (Search Server Express) 2008 - but guess it won't work either. As far as I understand that out-of-the-box its a browser-based search utility and more about the Office or rather now Sharepoint product portfolio than about Windows Server System.

Additionally, WDS (Windows Desktop Search) 4.0 - now Windows Search is offered as an update to Windows Server 2008 - that contractdicts the statement the file services (DFS) is not a peer of PC to PC. Before the update, Windows Server 2008 can be configured to add Windows Search Service. So that adds to the confusion.

So please Microsoft, join the concepts into one search concept - like the online pc with Windows 7. Please drive your new stuff forward instead of partitioning into different products what should have been a compositional design.

Takes too long for your guys - think about the hailstorm, my services, windows live/online ... and now may be kumo - a history of 2001 - 2008. Thinks changes allright - but as I remember the hailstorm story at the time was all about business model issues - not the compositional software design or eventually the technology. Get the product mangement straight.

Answer 12

We have the same problem. The fileserver (Windows Server 2008) indexes its shares. When accessing the share directly (\\server\share), Windows XP clients are able to perform an indexed search with WDS 4.0, but when accessing the same share on the same server (\\domain\namespace\share), WDS claims the folder is not indexed and thus cannot be searched. It's a real let down for this very useful feature.

I also do not understand what the big deal is, because DFS-shares are merely shortcuts to "real" shares, which will be accessed after the client resolves the link.

Answer 13

Thomas:  Please provide us with an update as to when this problem will be resolved.  Our organization has been unable to offer desktop search to our clients since WDS does not support DFS (we don't want each user manually indexing the server for performance reasons).

Answer 14

Philippe:  It's interesting that you say this.  I get the impression that MS does not use DFS in-house and hence they do not do much testing with it since they appear to have a lot of bugs relating to DFS.  For instance, Vista had problems adding Network Locations that referred to DFS targets:
http://social.msdn.microsoft.com/Forums/en-US/itprovistanetworking/thread/ca487972-f81b-48a0-83af-4fb9d05c08d3

We also use DFS to help hide the many multiple file servers we use and I would hate to move away from it. 

Answer 15

Any news on the next version of Windows Search? Will DFS shares be supported? We are anxiously waiting!

Answer 16

Anyone tried this?

http://support.microsoft.com/kb/972841 : Windows Search does not return files or folders that are under DFS-linked folders on a Windows Vista SP2 or on a Windows Server 2008 SP2-based computer

Answer 17

I tried KB972841 on Vista SP2, and WDS still won't use the remote index. I think the hotfix only works for local indices.

Answer 18

I'm having the same problem with Windows 7 RTM.

I have a Windows Server 2008 share that is indexed on the server using the new Index 4.0. Let's call this C:\foo.  When I access the file from a Windows 7 client via the direct share path, say, \\win2008server\foo, the Windows 7 client does get the index for the directory.  When I access the C:\foo directory from the Windows 7 client via DFS, say \\mydomain.com\foo, the Windows 7 client does not think the folder is indexed.  This, of course, makes it impossible to add the folder to a new Windows 7 library - as the libraries require that all added folders be indexed.

Is there a hotfix for Windows 7 RTM that address this issue?  I guess it is the same bug in Vista SP2.

Answer 19

Hi Andreas,

This still seems to be a problem even from a Windows 7 client. Is the indexing failing server server-side or client-side? If server-side, is it fixed in 2008 R2? Please and thank you for finding answers to these questions.

This has been a huge outstanding bug for nearly 1.5 years! So sloppy, Microsoft. So sloppy.

Answer 20

Well, I tested it and this is NOT fixed when connecting to a DFS share hosted on Server 2008 R2. So I guess if you want to use the new Library features of Windows 7, you can't use DFS with redirected home folders (which my company does, FYI).

Answer 21

Hello everyone

I am also in the same situation, and would also be very happy to see this issue (or at least lack of feature) sorted. As said earlier, having to choose between WDS and DFS is far from being the right solution. For now, we are using DFS, but thanks to new W2k8 R2 features we will have to reconsider that, depending on the connection, non indexed searches over Direct Access may be disastrous.

When I first tried WDS, it was not even working with network drives, it has taken some time to get sorted,  please keep on that way and fix it for DFS too.

Answer 22

same over here... dfs and redirected folders, a common solution and the Index does not work.

It;s time to fix this!

Answer 23

Is this the reason why I can't search mapped network drives?

Jens

Answer 24

We use DFS too - and have the same problem of course. Disappointing, considering we're using Windows 7 and Server 2008.

The only way to fix this for our users on the client-side is to use Offline Files - but this hardly seems to be a tidy solution.

I, too, am looking forward to any updates on this.

Thanks!

Jake

Answer 25

I also have the same problem with Windows 7 (Windows Search) and Windows Server 2008 R2 (DFS Namespace). It doesn't add anything to this topic, but just wanted to let you know.

I hope Microsoft will fix this soon...

Boudewijn

Answer 26

We've seen this problem with a Java application as well, on Vista SP2 and Windows 7.  This application fails to browse DFS roots using JFileChooser.

JFileChooser is failing to enter DFS folders because:

   BasicFileChooserUI.java::changeDirectory()  has code like:

                if (shellFolder.isLink()) {

                    File linkedTo = shellFolder.getLinkLocation()

   Win32ShellFolder2.java is telling it that the file  has an attribute Is_Link and furthermore cannot return linkLocation.  I.e. JFileChooser is asking the Windows shell system whether it thinks the file is a link or not.  Starting only with SP2, Vista has started reporting that it is a link from the Shell subsystem.  Somewhere along the line we then also fail to get the linklocation that basicFileChooserUI is looking for.

We verified that before Vista SP2, using standalone C++ console app, IShellFolder::GetAttributesOf() returned SFGAO_LINK= false, after Vista SP2, SFGAO_LINK= true for a share on a DFS root.  We can also see that the icons in Explorer have changed since the SP2 installation from ordinary file-folders to short-cuts.

The shell subsystem has changed from thinking that a DFS folder is not a link to thinking that it is.  This has broken JFileChooser's ability to traverse into the folder.

We noted that   KB972841 ("Windows Search does not return files or folders that are under DFS-linked folders on a Windows Vista SP2 or on a Windows Server 2008 SP2-based computer") says:

"This problem occurs because of an error in the Shell32.dll file in Windows Vista SP2 and in Windows Server 2008 SP2. This error causes the system not to treat the DFS-linked network shares as ordinary folders. Instead, the system treats the DFS-linked files like shortcuts. Therefore, they are not indexed or searched."

We installed this hot-fix and noticed that our DFS directories still had the short-cut icons associated with them, which they did not before SP2 installation.  And indeed they are still identified as SFGAO_LINK = true by the shell subsystem.

Just some more information, and observing that it affects more than just WDS.

Answer 27

Is there a way to disable the pop up messages that this problem generates until a fix is found?

Matt

Answer 28

It appears that the problems with DFS are more fundamental.  I stopped using it on servers due to mysterious file deletions.  It appears that MS have finally managed to replicate this issue... see the last post here:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23417210.html?cid=748#a25863848

I think DFS is still a flawed technology - you can't get a much bigger flaw than randomly deleting files due to a faulty algorithm.  The even more worrying thing is that it has been there for years.

Answer 29

Sounds like your issue is with FRS. DFS and FRS are not the same problem.

It is a client flaw that Windows Search cannot search DFS share index. It should be able to trivially resolve the DFS path to it's underlying UNC path and use that to locate the index. Sounds like it was just left out. Poor implementation. 

Answer 30

Just to complete this gloomy picture, I've discovered that Windows Storage Server 2008/64 also suffers from this issue. I have all my data as the targets of a few DFS mount points and cannot add any of them to any Library in W7, receiving the "must be indexed..." error.

Windows Search is pre-installed in this version of Server 2008.

Sigh.

Richard

---

RS

Answer 31

I have begun to take another stand on this problem with SP2010 coming out.

I have suspended use of DFS because business now requires those libraries to be available in the UI.

They like libraries.

Anyway I am going to look at SP2010 Foundation - if it supports the mapping of Windows 7 Libraries to the Sharepoint Libraries and how to integrate with Windows Search.

Sharepoint should be better for information retrieval in general.

Storage should be fine as well considering its enhanced database features. As far as I understand even binaries goes into Sharepoint now.

So that may be the answer to this question. DFS goes out while Sharepoint comes in. Seems logical anyway and I was already considering a bit apart from this issue when to migrate file systems to Sharepoint.
Additionally locally available file system resources becomes indeed local resources ... like the local interpretation with Windows 7 Libraries and also symbolic links.

So I think this is about a switch in the compositional design. The responsibility for local links gets delegated to Windows locally consistent with interpretation of symbolic links in Vista. Everything else is legacy and remains only for backward compatibility. It also allows for delegating storage responsibility from a Windows NTFS file system to a (Windows) Sharepoint file system also adding may be better information retrieval, versioning and more. That is at least the kind of perspective I am beginning to see here ... still both are Windows Server System with respect to information retrieval while storage properties are kind of different

DFS is rather old by now - and used for information retrieval ... and some storage stuff like replication ... so may be kind of need refactoring to get those two responsibilties apart. Just one example.

DFS is still valuable right now for RUP, Intellimirror stuff etc. - and in that respect leaves a number of issues to be answered.

I.e. what about Sharepoint and offline files if I decide to use Sharepoint this way?
Anyway a requirement could be now considering Sharepoint users will need to always be online to work (or explicitly download the file locally). So in that case offline files is not important.

So by design two different solutions ... "Windows Sharepoint" (allthough Office) vs. Windows NTFS with DFS and Shares - both kind of networked file systems but different with respect to design. It would not be the first time ... before network file systems in Windows aka Shares there were mapped drives ... but these where used by Windows as local drives ... and thus put a big strain on the network.

But still would be great having client sync with Sharepoint... will that be Syncframework? How much file system is there ... can I really delegate that responsbility to Sharepoint and already have most features available locally like shortcuts to files, right click and then file properties, sendto etc.

of course would need some SQL Server power in there ... but with DFS we are talking business or enterprise solutions anyway for the most here ... (not consumer) ...

I just consider this an alternate solution. In our case I guess most documents are Microsoft Office. So Sharepoint makes sense in carrying the weight.
Then you have other files - but with SP2010 if binary they go into a blob.

A number of questions to be answered which I need to take a look at.

 

 

Answer 32

I believe I have found a work around for Windows 7 Libraries and DFS shares.

I have tried this on my Windows 7 computer at work and have found this to work.

Step 1: Map a drive say Z: to the physical location \\servername\share

Step 2: Add Z: into your library.

Step 3: Remove your Z: drive. (Note, it should remove this location in your library once you do this - that is OK!)

Step 4: Remap your Z: drive to the DFS location \\domainname\namespace

Step 5: You should have your Z: drive back and it should be pointed at your DFS share. If not - add your Z: drive back in and it should be able to add the DFS folder back into your library.

Now I haven't done extensive testing with this. However I have restarted my machine and another users Windows 7 computer that I tried the same thing on and the Library kept the map to the DFS share even after a restart. I am not sure what happens if the server that you originally map to in Step 1 goes away and another server that contains the DFS share comes up in place of the original mapped server. If I get some time to test with that I will add my notes to that.

Anyways - everyone give that a shot and see what you come up with.

Answer 33

Hi all,

After reading all these messages, a follow up (TWO years now since beginning!):

Server 2008sp2x64 (using DFS for users shares), clients WXP & W7

ShareA is indexed, users with "network disk" as Home directory
X:   \\server1\shareA
Z:   \\domain1\namespace\shareA

From WXP client, Explorer/right-click ... I can search any of them, looking for a word I know it is there: it works

From W7 client, when I search in X: it finds filenames and files which contain that word
From W7 client, when I search in Z: it finds only filenames

Yes, I do know: nothing new...

My next step: get rid of DFS: back to \\server\share... not that I feel happy about that...

See you
RØ

Answer 34

How dissapointing...just terrible design; nothing else to say really.  DFS and Libraries are a huge boon to resource navigation, but they don't work together because of WDS? 

Glad I wasted my time trying to figure out why this wasn't working.  I usually grasp Microsoft design pretty quickly, but this is about as counterintuitive as it gets.

The tiny bit of good news is that folder redirection for the Library works - the bad news is it only works the first time.  During testing, I removed the existing redirected link only to discover I couldn't add it back because of this ridiculous oversight.  Apparently, the only way to "fix it" is to blank the profile; always a nice workaround -- not.  I haven't tried modifying the Library xml directly yet though.

I had hoped the group policy setting for -- User Configuration->Policies->Administrative Templates->Windows Components->Windows Explorer->Turn off Windows Libraries features that rely on indexed file data -- would resolve the issue, even if disabling features I would prefer available, but it had no obvious effect.

I won't be tearing down an already established resource navigation system that I can centrally manage, DFS, to replace it with a user-driven decentralized one, Libraries, that can be lost, even temporarliy, due to profile or AppData issues.  Come on people.

Is an update available for this issue?  Right now it's going to slow our Windows 7 deployment.

Hoping users don't hit Remove by accident,
Super Dave

Answer 35

Tell me about it.  This is the most absurd thing.  It's clear from other forum and blog posts that Microsoft has been aware of this problem since the release of WDS 4.0, and yet they still haven't fixed it for Win7 and 2008 R2.  Pathetic.  We too are not eager to give up the important flexibility and resiliency afforded by DFS just to get library functionality, despite the desire by some users to implement it.  Big time Microsoft fail.

Answer 36

WDS Team:

From the Technet article http://technet.microsoft.com/en-us/library/cc749449%28WS.10%29.aspx , Windows Vista+ can identify the DFS scope:

A DFS scope is defined as a folder in a domain-based DFS namespace that corresponds to a DFS link. If a network error is detected when connecting to a folder or a file in a domain-based DFS namespace, Offline Files in Windows Vista will not bring the whole domain offline (as it does in Windows XP). It will bring offline only the DFS link that includes the folder or file that had the error.

Consider the scenario of the following domain-based DFS namespace:

\\DFSdomain\folder1\folder2\folder3\folder4\file1

Assume that the namespace has the following configuration:

    * Folder2 is a DFS link to: \\server1\folder2
    * Folder4 is a DFS link to: \\server2\folder4

If there is a network error connecting to file1, only folder4 and file1 will be brought offline. The rest of the DFS namespace remains online. If there is a network error connecting to folder2 or folder3, these two folders are brought offline, but folder4 and file1 remain online.

Couldn't this logic be used to identify what server a DFS path is referencing and then perform a WDS remote query on that file server to provide the search results?   

This problem is very frustrating and is preventing our clients from leveraging the great benefits of WDS remote queries.  Note that eliminating DFS, or using Offline files for all of our clients (specifically desktops that are always online and used by multiple users) is not an option for us.

Please resolve this problem!

Answer 37

Any update on this from the WDS team? Any hope of an update or patch to allow WDS to resolve DFS paths? It is a huge oversight for WDS to not work with DFS!

Jared Pickerell

Answer 38

I had opened a case with PSS on this, but there is no real resolution:

"Microsoft is aware of this issue. However, at this time, there is no method or support for search using a DFS share.

The only method to accomplish this would be to use the server name and not the dfs name and to enable offline files.

 

This feature request has been recommended for the next version of Windows.

Please let me know if you have doubts regarding the same. Have a nice day ahead!!"

 

"Wes,

   As it stands today, there is no “official’ confirmation for the inclusion of DFS shares in the next generation of Windows.  Although  it has gathered sustained momentum due to customer feedback similar to yours and is expected to get considerable consideration for the next Windows release. I will archive this case at this time. However, if you have any questions, please feel free to give me a call or send me an email.

    I once again would like to thank you for all your time and patience in this case.

Have a very nice day ahead!

 

Regards,"

 

Answer 39

Here is another company with huge problems implementing Windows 7 because of this yet not fixed bug!

No chance, they don't even have their concept working, how about going to deploy this?

 

Should we open another case to wake them?

Answer 40

any update on this issue?

---

Lawfirm IT guy

Answer 41

This is SOOO TYPICAL of M$: another lousy-unfinished shitty job, dropping the ball randomly, leaving pieces laying around everywhere and not having the balls even to tell people "hey, losers, we don't care, you better forget about it because we're such a clueless, stupidly incompetent corporation we don't even know what we will do next day so get lost..."

Answer 42

I'd just like to add my voice to the cause ... DFS needs to be supported in WDS, come on Microsoft, this really is very poor ...

Answer 43

<blockquote><P>I had opened a case with PSS on this, but there is no real resolution:</P>
... As it stands today, there is no “official’ confirmation for the inclusion of DFS shares in the next generation of Windows. &nbsp;Although &nbsp;it has gathered sustained momentum due to customer feedback similar to yours and is expected to get considerable consideration for the next Windows release.<STRONG><SPAN></blockquote>

Just took a look to see how things wew going ...

Kind of worrying that no material has been announced about were we can expect MS filesystem and storage strategy to go.

The entire portfolio in Windows Server System has now been articulated from virtualization into the concept of a private cloud. With SMB's Sysadm's now also have to propose the business to buy 1 production server to save while spending to buy 2 additional servers for sysops i.e. for System Center + DPM. Ok, but the obvious consolidation argument has kind of vanished. Save money and conlidate into 1 server and buy 3. Arguments about effectiveness, orchestration and role are the right ones now - but may be a bit harder for some executives (results-orientation).

Anyway to plan ahead those "private clouds" would be very nice to know if DFS is out - so we can start planing to fase it out.

If DFS was used for orchestrating file systems within the business domain - that is constrainted to the LAN - that does not fit very well with the broad concept of private clouds including private cloud services on WAN.

Additionally System Center are jumping into the seat of orchestration. I.e. DFS is a behind orchestration thing that users are (should not be) aware of.

So my bet is, that we will see something like FSM (i.e. File System Manager) for System Center.

OK, great. Only thing is while at it - what about remvoing the management console from Windows Servers too?

All you need is System Center, right? Then you buy a license for every component or kind of responsibility you need to take. A backup manager, a file system manager and so on.

If so, all sysadmins then need to understand is that the middleware in Windows Servers are reduced to just unmanageable Windows Services. You can only manage Windows servers from now on - if you buy into the server and client licenses of System Center.

If not you have an unmanageable infrastructure. Everything inside Windows today is kind of downed then.

To reverse that - understand System Center is just the new Management Console (MMC) ... so let it be free. Additional ADVANCED ENTERPRISE packs can may be be paid.

Remove Management Console (MMC), Windows Server Backup (WSB), DFS, GPSI and so on orchestrating management features and integrate System Center as the new Management Console.

Replace WSB with Data Protection Managemer (DPM)
Replace DFS with some new File System Manager (FSM) - and please introduce deduplication at least into NTFS!!

... or lower the price of boxed Windows Servers without boxed management and only "Windows 2000" management.

If not, I will remain a workstation Windows freak - while servers will have to go NFS.

Because I get to build and box my own servers anyway because everything gets fragmented into tiny bits while somebody remains in thinking how do we put everything in its own box.

Only problem is the delivered servers becomes less and less complete.

Windows Servers used to be a finalized and boxed product. I might as well go Linux ... then I'm also in control. The TCO would be the same - but better and more flexible.

With Windows Server its becoming more obvious to me that I have actually started building my own servers or middleware like in the Linux or Java patching world.

This was not a problem with server 2003.

 

 

 

 

Answer 44

My main problem here is that MS should be more or very clear about the use of their Windows Server System portfolio.

I.e. you really need to understand the end of GPSI, MMC and so on - really grasp the different evolution on statements like "role is everything", workflow and on. Thus System Center is about orchestration.

So one portal coming into Windows Server System - then this is the actual state of Windows Server System.
I.e. when you go to MMC console or just Management subjects of WinServer including MMC it says phased out by System Center. Click here to go to System Center. Then its a different problem you'll need to buy the replacement.
I.e. when you go to some legacy data protection component is says "phased out by System Center (Data Protectition Managemer component).

Here something on where SC's is going:
http://www.windowsnetworking.com/articles_tutorials/Microsoft-System-Center-Roadmap.html

But MS needs to get its clouded picture of the cloud released of legacy stuff so people can understand their vision. Or they should stick with surplus compatibility and leave customers to decided. They can't go both ways, however.

Then you simply don't understand what goes on. Like:

- It does not work? Oh, yes - but you bought the wrong product.
- Or I don't like or will not pay of separate stuff in that magnitude. It's the future, go buy somewhere else.

- Right now people are more like saying: I don't understand it - conclusion: it does not work (for me). I will use it untill it stops working more or less completely. Then I go buy something else.

 

Answer 45

My main problem here is that MS should be more or very clear about the use of their Windows Server System portfolio.

I.e. you really need to understand the end of GPSI, MMC and so on - really grasp the different evolution on statements like "role is everything", workflow and on. Thus System Center is about orchestration.

So one portal please when browsing info coming into Windows Server System - then this is the actual state of Windows Server System.
I.e. when you go to MMC console or just Management subjects of WinServer including MMC it should say phased out by System Center. Click here to go to System Center. Then its a different problem you'll need to buy the replacement.
I.e. when you go to some legacy data protection component it should also say "phased out by System Center (Data Protectition Managemer component).

Here something on where SC's is going:
http://www.windowsnetworking.com/articles_tutorials/Microsoft-System-Center-Roadmap.html

But MS needs to get its clouded picture of the cloud released of legacy stuff so people can understand their vision. Or they should stick with surplus compatibility and leave customers to decided. They can't go both ways, however.

Then you simply don't understand what goes on. Like:

- It does not work? Oh, yes - but you bought the wrong product.
- Or I don't like or will not pay of separate stuff in that magnitude. It's the future, go buy somewhere else.

- Right now people are more like saying: I don't understand it - conclusion: it does not work (for me). I will use it untill it stops working more or less completely. Then I go buy something else.

 

Answer 46

The basic problem is that Microsoft is literally  FULL OF SH!T, they never tell you anything, you have to come to these idiotic forums, only to find out they just dropped the ball AGAIN.

 

Search is just another feature where Microsoft HAS NO F'N CLUE HOW TO DO IT PROPERLY AND EFFECTIVELY - look at the totally BROKEN, CLUNKY, USELESS CRAP THEY GAVE YOU IN WDINWOS & as Search... isn't that a f'n joke, seriously?

ANY OTHER OS can search machine-wide without having to "add filters"... ahhhh, it's so hilariously clueless-broken-crap it's not even funny anymore, it just shows how totally out of  touch these incompetent idiots @M$ are...

Answer 47

3 years have passed and no change, nice.

 

What I would like to know is how MS would like us to map the libraries for windows 7?

Answer 48

I'm shocked this is still an issue, pls Microsoft help us out here!

Answer 49

Any updates on this issue?

---

System Engineer - Schaubroeck Informatica

Answer 50

For years we are waiting for some word from Microsoft on how to deploy file servers with search capability on the client side and indexing on the server side.

Microsoft.... hello? Anyone there? Are we to all start using Google docs? Is Ballmer secretly dumping his Microsoft stock and loading up on Google? That is the only logical conclusion one could come to since Microsoft hasn't given any guidance in years on how to successfully implement the MOST BASIC functionality that users expect from a network: finding and accessing files.

 

Answer 51

Is anybody out there listening?

---

Aaron Marks

Answer 52

Hi Mr. Microsoft

What is the current status of this issue?

---

Marteinn

Answer 53

Hi Mr. Microsoft,

 

Any updates on this issue?

Answer 54

For years we are waiting for some word from Microsoft on how to deploy file servers with search capability on the client side and indexing on the server side.

(...) Microsoft hasn't given any guidance in years on how to successfully implement the MOST BASIC functionality that users expect from a network: finding and accessing files.

 

Couldn't agree more - it is so much asked for? Most of us use storage systems of many types and with a variety of filesystems: isn't DFS just to solve all our problems with integrating Linux-based SMB storage into AD?

Agreed, DFS integrates, but does not provide any usability when used with Windows 7 Libraries - have they simply forgotten?

PLEASE - let this topic be a reminder then!

Answer 55

So I'm wondering how you all go about working around this problem.

We now have three physical (and AD) sites where we have DFS replication between the 3 file servers.  We want and need users to be able to log into multiple sites, and also access the same shared content, so roaming profiles/folder redirects reference the DFS namespace.  This of course prevents us from making such shares indexed/searchable.

So what can we do?

Answer 56

We have 14 sites using DFS replication.  We haven't found any solution.  Since moving to Windows 7 we've given up on Search/Indexing.  Our users just heavily rely on shortcuts and folder organization.  We've been lucky they're mostly not too computer savy and clamoring for search. We've had 1 or two users try to 'solve' this problem on their own by making the contents of the file shares available offline on their computer.  Unfortunately they did this on the entire DFS root and not only quickly used up all their local free disk space on their C: drive, but ran into bugs in the Windows 7 implementation of Offline files which resulted in an inability to turn it off again.  I had to edit the registry, and manually delete the configuration files for the offline files subsystem to get their computers working again.  We then ran into an issue where we disabled offline file availability on our file servers to try and prevent users from doing this again.  This triggered another DFS-Windows 7 bug whereby all DFS namespace resolution would timeout, refresh, and act very 'buggy', even though none of the computers were trying to use Offiline files with the DFS shares.  We had to use Group Policy to completely disable the Offline Files service on all Windows 7 client machines in order to have the DFS namespace be stable/usable again.

The search works so well for Outlook and local computer files it's really a shame it has sat undeveloped for the enterprise market since XP.

Answer 57

This just gets sadder and sadder.  I was hoping that Search Server 2010 might hold the answer for us.  Installed a test server and configured it to search the local file server in its colo site.  Indexed a small share with 10 or so files - and the search results worked great in the web interface.  Only problems of course is that the search results link to that local server which users cannot reach from their branch workstations (only reachable when they are logged into citrix for remote access).

So I recreated the content source but this time used the dfs namespace instead of the direct server share name in search server.  It crawled just fine and reported the same 10 files were found, and I can see those 10 files in the index.  BUT when I run the search, no results are returned!!!  Argh.  Redid it again with the direct server name and it works immediately.

Not even search server can properly function with DFS shares??????????  Unbelievable!!!!

Answer 58

Ya, I had a very similar experience in the previous version of Search Server a few years ago (2008 I think?)  DFS is simply not supported.  It's unfortunate to hear nothing has changed in the last few years with any of their products related to search and DFS.  I haven't seen any indications yet of anything changing with Windows 8 either.  I just don't think they're paying any attention to Search anymore, it's last decade's buzz word.  All their attention is on the move to the Cloud now...

Answer 59

Just for the heck of it... +1

Answer 60

+1 here, too. Heck, +99 for all the times I've cursed this shortcoming.

But it turns out that Microsoft isn't telling us the whole truth. Here's an interesting revelation from MS's consumer side:

Zune knows how to add DFS shares to Win 7 Libraries!

Check out this Win 7 Explorer screenshot:

Like many geeks, I have a Windows domain at home, and all our data is stored on the SBS, including Zune media.

Search doesn't work, but at least the folders appear in the correct Libraries, and (other than Search) are fully usable. All of little use to the Enterprise except (a) as Proof-Of-Concept and (b) if someone can reverse-engineer the mechanism through which it occurs. To repro:

1. Download & install Zune, (using v4.8.2345 here). (You don't need a Zune or Windows Phone to do this, by the way.)
2. Click Settings (in tiny type on the top edge of the window) -->Software-->Collection.
3. Scroll down to the bottom. IIRC, the default is for Zune to use Libraries, in which case there will be a button labeled Manage Separately that you should NOT click. But if there's a button that says Align Folders, click it. This will merge the folders you choose with your Library.
4. By default, Zune uses the user's default media folders (including those redirected to DFS shares), but you can add folders. Click Music-->Manage and add folders from DFS shares. They need not contain media files.
5. Now look at your Win 7 Music Library. It will include the DFS folder.

Heheheh. They say it can't be done, but clearly it can.

Don't ask me how, though. I can't find "SyncWithJeff'sPC" anywhere in the Registry so it must be managed elsewhere. But if someone can reverse-engineer it, PLEASE post it here!

Answer 61

Microsoft,

Any update on this with Windows 8 and "Windows Server 8"? Your enterprise/business customers are really needing some help here on this problem!

-Jared 

Answer 62

Just edit the ".Library-ms" file in yourprofile\Appdata\Roaming\Microsoft\windows\librairies

And replace or add an <URL> tag

Answer 63

Just edit the ".Library-ms" file in yourprofile\Appdata\Roaming\Microsoft\windows\librairies

And replace or add an <URL> tag

Hello JustaBeginner,

I'm trying to understand if your suggestion is useful; unfortunately I think it is not! The contents of the XML files you mention (can be examined with Notepad) are inscrutable. There's no scope for simply "adding or replacing a <URL> tag" as you suggest. I've been trying to build these XML files as part of a logon script so that certain shares are created in "Libraries". To do this involves a fairly complex dive into MSDN code samples. In the end, I simply created example XML files that represented the library entries I wanted, then copied these into the users' profiles, in my case overwriting "documents.library-ms". Additionally I simply set entries like "videos" and "music" to hidden, as these were not wanted in the business environment where I am working. MS advise hiding, not removing.

RS

---

RS

Answer 64

Hello all,

Not a solution, but a workaround that made Libraries usable in connection with DFS at the customer where I am implementing a new W7 client. OS is W7 in conjunction with W2K8R2.

There's a new group policy setting in W7:

Turn off Windows Libraries features that rely on indexed file data

Setting Path:
User Configuration/Administrative Templates/Windows Components/Windows Explorer

Supported On:
At least Windows 7 or Windows Server 2008 R2

Explanation

This policy setting allows you to turn off Windows Libraries features that need indexed file metadata to function properly. If you enable this policy, some Windows Libraries features will be turned off to better handle included folders that have been redirected to non-indexed network locations.
Setting this policy will:
* Disable all Arrangement views except for "By Folder"
* Disable all Search filter suggestions other than "Date Modified" and "Size"
* Disable view of file content snippets in Content mode when search results are returned
* Disable ability to stack in the Context menu and Column headers
* Exclude Libraries from the scope of Start search
This policy will not enable users to add unsupported locations to Libraries.

If you enable this policy, Windows Libraries features that rely on indexed file data will be disabled.
If you disable or do not configure this policy, all default Windows Libraries features will be enabled.

As it says on the tin, "This policy will not enable users to add unsupported locations to libraries", however I found that setting this allowed me (or users) to add shares hosted on DFS mount points without receiving that annoying yellow error bar message aboiut unsupported locations. So the description of the effect of the policy is a bit less than clear.

So at least now I could change "Documents" to point to \\company\users\%username% without the error.

Better than nothing, I suppose, but I wish MS would get on and fix this bug!

I want to try Windows 8 and Server 8 to see if that makes any difference. I suspect not. Anyone know different?

RS

---

RS

Answer 65

Hello all,

Not a solution, but a workaround that made Libraries usable in connection with DFS at the customer where I am implementing a new W7 client. OS is W7 in conjunction with W2K8R2.

There's a new group policy setting in W7:

Turn off Windows Libraries features that rely on indexed file data

Setting Path:
User Configuration/Administrative Templates/Windows Components/Windows Explorer

Supported On:
At least Windows 7 or Windows Server 2008 R2

Explanation

This policy setting allows you to turn off Windows Libraries features that need indexed file metadata to function properly. If you enable this policy, some Windows Libraries features will be turned off to better handle included folders that have been redirected to non-indexed network locations.
Setting this policy will:
* Disable all Arrangement views except for "By Folder"
* Disable all Search filter suggestions other than "Date Modified" and "Size"
* Disable view of file content snippets in Content mode when search results are returned
* Disable ability to stack in the Context menu and Column headers
* Exclude Libraries from the scope of Start search
This policy will not enable users to add unsupported locations to Libraries.

If you enable this policy, Windows Libraries features that rely on indexed file data will be disabled.
If you disable or do not configure this policy, all default Windows Libraries features will be enabled.

As it says on the tin, "This policy will not enable users to add unsupported locations to libraries", however I found that setting this allowed me (or users) to add shares hosted on DFS mount points without receiving that annoying yellow error bar message aboiut unsupported locations. So the description of the effect of the policy is a bit less than clear.

So at least now I could change "Documents" to point to \\company\users\%username% without the error.

Better than nothing, I suppose, but I wish MS would get on and fix this bug!

I want to try Windows 8 and Server 8 to see if that makes any difference. I suspect not. Anyone know different?

RS

---

RS

Answer 66

Just edit the ".Library-ms" file in yourprofile\Appdata\Roaming\Microsoft\windows\librairies

And replace or add an <URL> tag

Hello JustaBeginner,

I'm trying to understand if your suggestion is useful; unfortunately I think it is not! The contents of the XML files you mention (can be examined with Notepad) are inscrutable. There's no scope for simply "adding or replacing a <URL> tag" as you suggest. I've been trying to build these XML files as part of a logon script so that certain shares are created in "Libraries". To do this involves a fairly complex dive into MSDN code samples. In the end, I simply created example XML files that represented the library entries I wanted, then copied these into the users' profiles, in my case overwriting "documents.library-ms". Additionally I simply set entries like "videos" and "music" to hidden, as these were not wanted in the business environment where I am working. MS advise hiding, not removing.

RS

---

RS

Powershell natively supports XML editing.  So, you can potentially use Powershell to add this data to the XML file.  I've used the code from the site below to remove the public folders from the Libraries, but you can use it as a basis to accomplish what you're trying:

http://social.technet.microsoft.com/Forums/ar/ITCG/thread/6f9803a1-f5b6-4f88-a830-b888df8df61d

Answer 67

Aakash,

This is terrifically helpful - thanks! I really have a problem trying to understand why MS make it so hard to turn off the consumer-oriented stuff that is typically not wanted in a business environment, for example Public Folders.

Thanks again,

Richard

---

RS

Answer 68

Yes i've got an update: Windows 8 RP + Server 2012 RC = exact same behaviour: unable to add DFS shares to a W8 Library using the standard dialog boxes.

Hopefully, third party Library utilities are still working in Windows 8.

I think this problem will never be solved.

Answer 69

With all the attention given to file service in WS2012, hard to believe they didn't finally address using Search with DFS. Thanks for the report.

Answer 70

Silly. Libraries were kind of cool. And are really the perfect way to surface business resources to a machine. Avoids mapping drive names, and dealing with all that. But, there's no way I'll discard the functionality of DFS for that.