Web Service Extensions per Application

Hello,
is there any way to disable WebDAV extension just for my application?
Running IIS6.

Thanks,
Jan

RE: Web Service Extensions per Application

Hi Jan,

The Web Service Extenstions list is a global WWW service level setting. So
it cannot be configured on the single site level to disable WebDav
independently.

To limit WebDav requests handled by IIS httpext.dll on a single site or
virtual directory, we can only allow Read and disable Write,Directory
browsing in their Home(Virtual) Directory tab. Then users try to open the
site/vdir as web folder will see a blank folder(due to Directory browsing
is disabled) and cannot upload any files(Write disabled).

A more solid way is installing UrlScan filter on the single site to deny
WebDAV requests.

UrlScan Security Tool
http://www.microsoft.com/technet/security/tools/urlscan.mspx

After URLscan is installed, we can remove its ISAPI filter from WWW global
setting: Right-click the Web Sites folder in IIS6, remove the UrlScan
filter from ISAPI filters tab. Then manually add this filter
(\WINDOWS\system32\inetsrv\urlscan\urlscan.dll) into your web site/vdir's
property->ISAPI filters tab. Run iisreset command to restart IIS.

By default, the http verbs of WebDav(OPTIONS,PROPFIND...) are denied in
\WINDOWS\system32\inetsrv\urlscan\urlscan.ini. So users will no longer be
able to open the site/vdir as web folders in browser.

I hope the info above answered your question. Please let me know if you
have any further concern.

Have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Web Service Extensions per Application

Hello WenJun Zhang!
Thank you for your answer. Unfortunately, your solution does not solve my
problem. I thought there could be application-specific setting because there
is "Allow all extensions for specific application" setting in the IIS
console. That way, I could achieve my request by prohibiting the extensions
by default, and use this setting to allow it back for all other applications
on the server; couldn't I?

The reason why I'm asking for this is, that my ASP.NET 2.0 application
handles the WebDAV requests itself. The IIS built-in "WebDAV extension"
however, handles these requests before they have ever chance to reach my
application. If I prohibit this extension, everything works perfectly. But,
I don't want to force whole IIS server to not use WebDAV extensions
(similarly with SharePoint and FrontPage Server Extensions which cause
similar behaviour). (Actually I would, but IT Admins are not happy with it.
:-) )

So if there is any other way to stop IIS WebDAV extension to steal my
requests, that will do.
Jan


""WenJun Zhang[msft]"" wrote in message
news:nICACZd#HHA.360@TK2MSFTNGHUB02.phx.gbl...
> Hi Jan,
>
> The Web Service Extenstions list is a global WWW service level setting. So
> it cannot be configured on the single site level to disable WebDav
> independently.
>
> To limit WebDav requests handled by IIS httpext.dll on a single site or
> virtual directory, we can only allow Read and disable Write,Directory
> browsing in their Home(Virtual) Directory tab. Then users try to open the
> site/vdir as web folder will see a blank folder(due to Directory browsing
> is disabled) and cannot upload any files(Write disabled).
>
> A more solid way is installing UrlScan filter on the single site to deny
> WebDAV requests.
>
> UrlScan Security Tool
> http://www.microsoft.com/technet/security/tools/urlscan.mspx
>
> After URLscan is installed, we can remove its ISAPI filter from WWW global
> setting: Right-click the Web Sites folder in IIS6, remove the UrlScan
> filter from ISAPI filters tab. Then manually add this filter
> (\WINDOWS\system32\inetsrv\urlscan\urlscan.dll) into your web site/vdir's
> property->ISAPI filters tab. Run iisreset command to restart IIS.
>
> By default, the http verbs of WebDav(OPTIONS,PROPFIND...) are denied in
> \WINDOWS\system32\inetsrv\urlscan\urlscan.ini. So users will no longer be
> able to open the site/vdir as web folders in browser.
>
> I hope the info above answered your question. Please let me know if you
> have any further concern.
>
> Have a nice day.
>
> Sincerely,
>
> WenJun Zhang
>
> Microsoft Online Community Support
>
> ==================================================
>
> Get notification to my posts through email? Please refer to:
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at:
>
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

Re: Web Service Extensions per Application

Jan,

IisShield [1], similarly to UrlScan, can filter HTTP requests based on very
similar configuration file. This tool is now open source, so you can even
debug its behavior. There is a documentation [2] file included too.

While UrlScan is set up on server wide basis only, IisShield can be setup
per Zone (see below).
I hope IisShield fits your needs here.

================== quote [3] ==================
IisShield is flexible enough so that rules can be split into zones allowing
the filtering process to be applied in a per-zone scope versus a per-server
scope. Zones are used to specify which requests are included or excluded
requests from the filtering engine. A zone contains the following optional
items:
a.. target address
b.. target port
c.. target url
d.. rules file
A zone can also override the default rules file by specifying a rules file
to be applied to all requests part of the zone. For a request t be
considered part of a zone, the following steps are taken whenever a request
comes into IIS:
a.. If target address is defined, then the target address of the request
must match target address
b.. If target port is defined, then the target port of the request must
match target port
c.. If target url is defined, then the url of the request must start with
target url
The zone that first matches a request is the chosen zone. Zones are checked
in the order they are defined in the configuration file. Zones that do not
define target address, target port and target url are ignored.
================== end quote ==================

Tiago Halm

[1] http://www.codeplex.com/iisshield
[2] http://www.codeplex.com/iisshield/Release/ProjectReleases.as px
[3]
http://www.codeplex.com/iisshield/Wiki/View.aspx?title=Featu res&referringTitle=Home

Re: Web Service Extensions per Application

Tiago,
If I get it right, the IisShield behaves like firewall and allows/denies
IIS, or specific site to process specific requests. If it allows the
request - and I need to allow them, actually through whole server; how does
it prevent IIS from handling it by the WebDAV extension?
I mean it seems to me that denying the request is a new feature which I
don't need and allowing the request will bring me to the previous situation
I'm trying to solve.
If I am wrong, correct me, please.

Jan

"Tiago Halm" wrote in message
news:#8MZasj#HHA.1204@TK2MSFTNGP03.phx.gbl...
> Jan,
>
> IisShield [1], similarly to UrlScan, can filter HTTP requests based on
> very similar configuration file. This tool is now open source, so you can
> even debug its behavior. There is a documentation [2] file included too.
>
> While UrlScan is set up on server wide basis only, IisShield can be setup
> per Zone (see below).
> I hope IisShield fits your needs here.
>
> ================== quote [3] ==================
> IisShield is flexible enough so that rules can be split into zones
> allowing the filtering process to be applied in a per-zone scope versus a
> per-server scope. Zones are used to specify which requests are included or
> excluded requests from the filtering engine. A zone contains the following
> optional items:
> a.. target address
> b.. target port
> c.. target url
> d.. rules file
> A zone can also override the default rules file by specifying a rules file
> to be applied to all requests part of the zone. For a request t be
> considered part of a zone, the following steps are taken whenever a
> request comes into IIS:
> a.. If target address is defined, then the target address of the request
> must match target address
> b.. If target port is defined, then the target port of the request must
> match target port
> c.. If target url is defined, then the url of the request must start with
> target url
> The zone that first matches a request is the chosen zone. Zones are
> checked in the order they are defined in the configuration file. Zones
> that do not define target address, target port and target url are ignored.
> ================== end quote ==================
>
> Tiago Halm
>
> [1] http://www.codeplex.com/iisshield
> [2] http://www.codeplex.com/iisshield/Release/ProjectReleases.as px
> [3]
> http://www.codeplex.com/iisshield/Wiki/View.aspx?title=Featu res&referringTitle=Home
>

Re: Web Service Extensions per Application

Jan,

You want the WebDAV requests to be handled. However, for a specific
site or virtual directory, you want the WebDAV extension to *ignore*
these requests and let ASP.NET handle the requests. If IisShield was
applied in this scenario, instead of *ignore*, the requests would be
*rejected*. I may have got it wrong. I believe we were all thinking
the original question was about disabling the processing of a request,
not ignore it.

On another note, I'm curious as to how you handle the WebDAV requests
yourself in ASP.NET.

Finally, you could use an ISAPI Filter to "catch" the WebDAV requests
going to your webapp, change the method to an ordinary GET (which
would possibly bypass the httpext.dll extension) and then let ASP.NET
handle the request as if it was a WebDAV request (ex: PROPFIND). Its
kind of a hack and I don't really know if it would work and it all
depends on how you *handle* the WebDAV request yourself.

NOTE: ISAPI Filters for IIS 5.x and IIS 6 can be built in .NET using
Filter.NET - http://www.codeplex.com/filterdotnet.

Tiago Halm

Re: Web Service Extensions per Application

> I believe we were all thinking
> the original question was about disabling the processing of a request,
> not ignore it.

Well maybe my mistake here. I don't want to disable processing of a request,
I want to disable single Web Service Extension which steals it.
(and not affecting any other web sites which may depend on it)

> On another note, I'm curious as to how you handle the WebDAV requests
> yourself in ASP.NET.

Well nothing extraordinary here, I just have an IHttpHandler, which is
registered through web.config section. It handles standard
methods like OPTIONS, PROPFIND, LOCK etc. and in this case it uses SQL
database as storage for the documents. As I said, when nobody steals my
requests it works as standard WebDAV server which eg. Office can talk to.

> Finally, you could use an ISAPI Filter to "catch" the WebDAV requests
> going to your webapp, change the method to an ordinary GET (which
> would possibly bypass the httpext.dll extension) and then let ASP.NET
> handle the request as if it was a WebDAV request (ex: PROPFIND). Its
> kind of a hack and I don't really know if it would work and it all
> depends on how you *handle* the WebDAV request yourself.

Well if it would work as you think, it would require at least to encode the
original method somehow in the request, likely in custom HTTP header. And
although this would probably work, it would require me to 1) change my
WebDAV-compliant handler to do hacking, 2) Create whole new library - ISAPI
filter and 3) Convince the IT admins of customers to allow me to register my
own ISAPI filter on their internal servers. Since customers are mostly
government institutions that's not very likely. I don't know why, but they
feel much more comfortable prohibiting than allowing... :))

But thanks for the idea, at least some workaround seems to exist.
Jan

Re: Web Service Extensions per Application

Hi Jan,

I understand your problem now: you use a http handler to process webdav
requests on a specific virtual directory and the other webdav sites still
need the built-in webdav function(httpext.dll). I agree the scenario seems
quite reasonable. I will go ahead to discuss it in our internal IIS group
to see if anybody else has an ideal solution or work around for your case.
If there is any update on this, I will post here to let you know ASAP.

Thanks.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Web Service Extensions per Application

Hi Jan,

I've confirmed that this is a known limitation of WebDAV on IIS6 and
eariler with our product group. Writing custom ISAPI filter to catch WebDAV
requests before they are handled by IIS is the only solution currently.

This is a specific issue to WebDAV since httpext.dll isn't a common ISAPI
dll registered per site level. It acts as a built-in extenstion of all
worker processes which is registered in InProcessIsapiApps property at
W3SVC level(uninstallation is not supported). Other service extensions and
filters don't have the problem since we can remove them from a web site if
it's not required.

So your understanding is very much appreciated. In IIS7 things will be much
better though.

Thanks and have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Web Service Extensions per Application

Hi WenJun Zhang,
thank you for finding that out for me. My last question at the moment
perhaps is - could I create such ISAPI filter, which would redirect the
WebDAV requests direct to my ASP.NET application, that means, I wouldn't
have to change the ASP.NET code itself? (as it does everything well)

Thanks,
Jan


""WenJun Zhang[msft]"" wrote in message
news:DDOspaEAIHA.240@TK2MSFTNGHUB02.phx.gbl...
> Hi Jan,
>
> I've confirmed that this is a known limitation of WebDAV on IIS6 and
> eariler with our product group. Writing custom ISAPI filter to catch
> WebDAV
> requests before they are handled by IIS is the only solution currently.
>
> This is a specific issue to WebDAV since httpext.dll isn't a common ISAPI
> dll registered per site level. It acts as a built-in extenstion of all
> worker processes which is registered in InProcessIsapiApps property at
> W3SVC level(uninstallation is not supported). Other service extensions and
> filters don't have the problem since we can remove them from a web site if
> it's not required.
>
> So your understanding is very much appreciated. In IIS7 things will be
> much
> better though.
>
> Thanks and have a nice day.
>
> Sincerely,
>
> WenJun Zhang
>
> Microsoft Online Community Support
>
> ==================================================
>
> Get notification to my posts through email? Please refer to:
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at:
>
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

Re: Web Service Extensions per Application

Try Wildcard Application Mapping the ASPNET_ISAPI.DLL for the vdir in
question. I forget the ordering, but I think it makes ASP.Net handlers
execute before the built-in WebDAV handler of IIS -- which would allow
your httpHandler to "steal" the request.

If that doesn't work, then I can only imagine an ISAPI Filter which
alters the incoming request to fool IIS's WebDAV handler, and the
first thing your httpHandler does is to revert the incoming request
back to normal.

No, it's not possible to create an ISAPI Filter that redirects the
WebDAV requests directly to your ASP.Net application. There are
several request pipeline stages in between when the ISAPI Filter
intercepts and when your ASP.Net application executes, and IIS simply
does not allow you to skip/reorder the request pipeline stages. It
wouldn't make a lot of sense, even if it is what you need.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Sep 27, 4:51 pm, "Jan Kucera" wrote:
> Hi WenJun Zhang,
> thank you for finding that out for me. My last question at the moment
> perhaps is - could I create such ISAPI filter, which would redirect the
> WebDAV requests direct to my ASP.NET application, that means, I wouldn't
> have to change the ASP.NET code itself? (as it does everything well)
>
> Thanks,
> Jan
>
> ""WenJun Zhang[msft]"" wrote in message
>
> news:DDOspaEAIHA.240@TK2MSFTNGHUB02.phx.gbl...
>
>
>
> > Hi Jan,
>
> > I've confirmed that this is a known limitation of WebDAV on IIS6 and
> > eariler with our product group. Writing custom ISAPI filter to catch
> > WebDAV
> > requests before they are handled by IIS is the only solution currently.
>
> > This is a specific issue to WebDAV since httpext.dll isn't a common ISAPI
> > dll registered per site level. It acts as a built-in extenstion of all
> > worker processes which is registered in InProcessIsapiApps property at
> > W3SVC level(uninstallation is not supported). Other service extensions and
> > filters don't have the problem since we can remove them from a web site if
> > it's not required.
>
> > So your understanding is very much appreciated. In IIS7 things will be
> > much
> > better though.
>
> > Thanks and have a nice day.
>
> > Sincerely,
>
> > WenJun Zhang
>
> > Microsoft Online Community Support
>
> > ==================================================
>
> > Get notification to my posts through email? Please refer to:
> >http://msdn.microsoft.com/subscriptions/managednewsgroups/d efault.asp...
> > ications.
>
> > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> > where an initial response from the community or a Microsoft Support
> > Engineer within 1 business day is acceptable. Please note that each follow
> > up response may take approximately 2 business days as the support
> > professional working with you may need further investigation to reach the
> > most efficient resolution. The offering is not appropriate for situations
> > that require urgent, real-time or phone-based interactions or complex
> > project analysis and dump analysis issues. Issues of this nature are best
> > handled working with a dedicated Microsoft Support Engineer by contacting
> > Microsoft Customer Support Services (CSS) at:
>
> >http://msdn.microsoft.com/subscriptions/support/default.asp x.
>
> > ==================================================
>
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.- Hide quoted text -
>
> - Show quoted text -

Re: Web Service Extensions per Application

Hi David!

"David Wang" wrote in message
news:1190985234.128207.221780@22g2000hsm.googlegroups.com...
> Try Wildcard Application Mapping the ASPNET_ISAPI.DLL for the vdir in
> question. I forget the ordering, but I think it makes ASP.Net handlers
> execute before the built-in WebDAV handler of IIS -- which would allow
> your httpHandler to "steal" the request.
>

Well, according tou your post
http://blogs.msdn.com/david.wang/archive/2005/10/15/Why-Wild card-application-mapping-can-disable-Default-Document-resolu tion.aspx
this would most probably block any ASP web sites on the server, wouldn't it?

So instead of disabling that ones which uses WebDAV built-in extension I
would disable ASP ones and I guess some others as well.
Or I just might get it wrong...

> If that doesn't work, then I can only imagine an ISAPI Filter which
> alters the incoming request to fool IIS's WebDAV handler, and the
> first thing your httpHandler does is to revert the incoming request
> back to normal.

Yes, this solution seems the only to which we can rely on...I'll hold it for
worst-case.

> No, it's not possible to create an ISAPI Filter that redirects the
> WebDAV requests directly to your ASP.Net application. There are
> several request pipeline stages in between when the ISAPI Filter
> intercepts and when your ASP.Net application executes, and IIS simply
> does not allow you to skip/reorder the request pipeline stages. It
> wouldn't make a lot of sense, even if it is what you need.

If the filters are allowed to take final control over the request, I think
that allowing to configure their order makes some sense.


New question though, If I do use the wildcard mapping to ASPNET_ISAPI.DLL,
am I still required to map the specific (custom) extensions to ASP.NET and
register the handler in web.config?

Thank you,
Jan

Re: Web Service Extensions per Application

On Sep 28, 7:27 am, "Jan Kucera" wrote:
> Hi David!
>
> "David Wang" wrote in message
>
> news:1190985234.128207.221780@22g2000hsm.googlegroups.com...
>
> > Try Wildcard Application Mapping the ASPNET_ISAPI.DLL for the vdir in
> > question. I forget the ordering, but I think it makes ASP.Net handlers
> > execute before the built-in WebDAV handler of IIS -- which would allow
> > your httpHandler to "steal" the request.
>
> Well, according tou your posthttp://blogs.msdn.com/david.wang/archive/2005/10/15/Why- Wildcard-appl...
> this would most probably block any ASP web sites on the server, wouldn't it?
>
> So instead of disabling that ones which uses WebDAV built-in extension I
> would disable ASP ones and I guess some others as well.
> Or I just might get it wrong...
>
> > If that doesn't work, then I can only imagine an ISAPI Filter which
> > alters the incoming request to fool IIS's WebDAV handler, and the
> > first thing your httpHandler does is to revert the incoming request
> > back to normal.
>
> Yes, this solution seems the only to which we can rely on...I'll hold it for
> worst-case.
>
> > No, it's not possible to create an ISAPI Filter that redirects the
> > WebDAV requests directly to your ASP.Net application. There are
> > several request pipeline stages in between when the ISAPI Filter
> > intercepts and when your ASP.Net application executes, and IIS simply
> > does not allow you to skip/reorder the request pipeline stages. It
> > wouldn't make a lot of sense, even if it is what you need.
>
> If the filters are allowed to take final control over the request, I think
> that allowing to configure their order makes some sense.
>
> New question though, If I do use the wildcard mapping to ASPNET_ISAPI.DLL,
> am I still required to map the specific (custom) extensions to ASP.NET and
> register the handler in web.config?
>
> Thank you,
> Jan


With ASP.Net 2.0, it is possible to pass ASP requests onward back to
IIS from ASP.Net, so yes, it can work.

No, Filters are not allowed to take control. They are not allowed to
modify event firing sequence. IIS must remain in control to invoke
Filters and Modules to modify behavior. It is not exposed in IIS6, and
it is explicitly disallowed in IIS7.

If you do wildcard application mapping to ASPNET_ISAPI.DLL, that just
tells IIS to route the requests to ASP.Net. You still have to map the
handlers in web.config for ASP.Net to handle it properly.

That is the nature of a disjointed request pipeline, where you are
trying to extend IIS functionality with managed code. These seams are
easily seen by needing to configure both httpHandler and scriptMaps to
route a request for ASP.Net to handle, as well as inability for
managed code to extend IIS authentication.

This is resolved in IIS7 with the Integrated Pipeline, which allows
extension of IIS functionality with both native and managed code as
first-class citizen (well, managed code will always be like 1.5-class
citizen).

So, what you want to do can be easily done on IIS7. It can be hacked
together on IIS6 with ASP.Net 2.0.

And I guarantee that the hacks with IIS6 and ASP.Net 2.0 are all
broken by default on IIS7 -- you need to figure it out all over again
because such legacy configuration is not supported, but it should be
easier on IIS7 to do it the right way.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: Web Service Extensions per Application

Hello Jan,
Thanks for David's reply.

Wen-Jun Zhang is on vacation this week. I'm his backback Wen-Yuan Wang.
I just want to check if there is anything we can help with. If so, please
feel free to update here again.
We are glad to assist you.

Have a great day,
Best regards,

Wen Yuan
Microsoft Online Partner Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.