|
Home > Archive > MS SQL Server OLAP > December 2005 > AS 2005 HTTP access with Basic Authentication
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
AS 2005 HTTP access with Basic Authentication
|
|
| Scott Ivey 2005-12-08, 11:24 am |
| Hi all - hopefully someone here can help me out with this. I have an open
ticket on this with MS as well, and none of their techs seem to know how to
help me. I have enabled HTTP access to our Analysis Services 2005 server by
following the steps at
http://www.microsoft.com/technet/pr...5/httpasws.mspx -
however, I need to use BASIC AUTHENTICATION instead of Windows Integrated.
Once I enable basic and disable integrated, everything just stops working. I
found another article saying that AS 2005 ignores basic authentication by
default, and gives steps to change the setting, but the screen that they talk
about doesn't exist, and the one that does that looks similar doesn't list
the properties necessary to change. Link to that article is...
http://msdn2.microsoft.com/en-us/library/ms174573.aspx. It says the
following - "Based on the default setting of 1, Analysis Services rejects
client requests that are submitted by using Basic authentication. To accept
client requests that use Basic authentication, change the setting for this
property to 0." I tried to add the property directly thru msmdsrv.ini file,
but that didn't seem to work either. Anyone else have any other ideas? I'm
desperate here - I'm supposed to be on vacation tomorrow, and if I don't have
this fixed by then, i'm in deep $*%!.
Thanks!
Scott Ivey
| |
| Edward Melomed [MSFT] 2005-12-08, 8:24 pm |
| Once you enabled the Basic Authentication you need to make sure you specify
your credentials.
You can do it ever by specifying "user" and "password" connection string
properties in your connection string.
Or you can add "prompt=1" to your connection string and you will get
additional dialog asking for your credentials.
Edward Melomed
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Scott Ivey" <iveys@online.nospam> wrote in message
news:3B651890-487C-4A78-B1DB- 635E99C12C3F@microso
ft.com...
> Hi all - hopefully someone here can help me out with this. I have an open
> ticket on this with MS as well, and none of their techs seem to know how
> to
> help me. I have enabled HTTP access to our Analysis Services 2005 server
> by
> following the steps at
> http://www.microsoft.com/technet/pr...5/httpasws.mspx -
> however, I need to use BASIC AUTHENTICATION instead of Windows Integrated.
> Once I enable basic and disable integrated, everything just stops working.
> I
> found another article saying that AS 2005 ignores basic authentication by
> default, and gives steps to change the setting, but the screen that they
> talk
> about doesn't exist, and the one that does that looks similar doesn't list
> the properties necessary to change. Link to that article is...
> http://msdn2.microsoft.com/en-us/library/ms174573.aspx. It says the
> following - "Based on the default setting of 1, Analysis Services rejects
> client requests that are submitted by using Basic authentication. To
> accept
> client requests that use Basic authentication, change the setting for this
> property to 0." I tried to add the property directly thru msmdsrv.ini
> file,
> but that didn't seem to work either. Anyone else have any other ideas?
> I'm
> desperate here - I'm supposed to be on vacation tomorrow, and if I don't
> have
> this fixed by then, i'm in deep $*%!.
>
>
> Thanks!
>
> Scott Ivey
| |
| Scott Ivey 2005-12-08, 8:24 pm |
| I used prompt=1 in the connect string, but that doesn't work - I never get
prompted. Specifying user & password does work - but I'd like to have it
prompt for password instead. Are there any ideas why the prompt doesn't work?
Scott
"Edward Melomed [MSFT]" wrote:
> Once you enabled the Basic Authentication you need to make sure you specify
> your credentials.
> You can do it ever by specifying "user" and "password" connection string
> properties in your connection string.
> Or you can add "prompt=1" to your connection string and you will get
> additional dialog asking for your credentials.
>
>
> Edward Melomed
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>
> "Scott Ivey" <iveys@online.nospam> wrote in message
> news:3B651890-487C-4A78-B1DB- 635E99C12C3F@microso
ft.com...
>
>
>
| |
| Edward Melomed [MSFT] 2005-12-08, 8:24 pm |
| That is strange.
What client application you are using?
If you have MDXSample app , try in the connection dialog specify provider as
"MSOLAP;prompt=1"
And you should see another box appear titled "Multidimensional Connection
9.0"
Edward Melomed
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Scott Ivey" <iveys@online.nospam> wrote in message
news:9C657D31-EA77-4B69-866B- 841100DAE9F7@microso
ft.com...[color=darkred]
>I used prompt=1 in the connect string, but that doesn't work - I never get
> prompted. Specifying user & password does work - but I'd like to have it
> prompt for password instead. Are there any ideas why the prompt doesn't
> work?
>
>
> Scott
>
> "Edward Melomed [MSFT]" wrote:
>
| |
| Scott Ivey 2005-12-08, 8:24 pm |
| I'm using OWC 11 as the app, hosted inside sharepoint site. prompt=1 does
nothing. I've tried changing every IE setting that I could think of to see
if that had anything to do with it, but no luck.
Scott
"Edward Melomed [MSFT]" wrote:
> That is strange.
>
> What client application you are using?
>
> If you have MDXSample app , try in the connection dialog specify provider as
> "MSOLAP;prompt=1"
> And you should see another box appear titled "Multidimensional Connection
> 9.0"
>
> Edward Melomed
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Scott Ivey" <iveys@online.nospam> wrote in message
> news:9C657D31-EA77-4B69-866B- 841100DAE9F7@microso
ft.com...
>
>
>
| |
| Peter Yang [MSFT] 2005-12-09, 3:24 am |
| Hi Scott,
The following is the connecting string works on my side for basic
authentication:
<script language="vbscript">
sub button1_onclick()
PivotTable1.ConnectionString = "Provider=MSOLAP;" + _
"Data Source=http://localhost/as2005/msmdpump.dll;Initial
Catalog=adventurewor
ksdw;prompt=1"
PivotTable1.DataMember = "adventure works dw"
end sub
</script>
I wonder if you test this on different client machines. In addition, I
suggest that you use a html file to test directly other than a aspx file.
If the VD hosting the html file is different from the VD hosting
msmdump.dll, you may check security settings for both VDs.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
====================
====================
=============
Business-Critical Phone Support (BCPS) provides you with technical phone
support at no charge during critical LAN outages or "business down"
situations. This benefit is available 24 hours a day, 7 days a week to all
Microsoft technology partners in the United States and Canada.
This and other support options are available here:
BCPS:
https://partner.microsoft.com/US/te...erview/40010469
Others: https://partner.microsoft.com/US/te...upportoverview/
If you are outside the United States, please visit our International
Support page:
http://support.microsoft.com/defaul...a
l.aspx.
====================
====================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>Thread-Topic: AS 2005 HTTP access with Basic Authentication
>thread-index: AcX8SvrZLk9yEPPgQmOE
IhphOPvCyA==
>X-WBNR-Posting-Host: 66.115.208.110
>From: "=?Utf-8?B?U2NvdHQgSXZleQ==?=" <iveys@online.nospam>
>References: <3B651890-487C-4A78-B1DB- 635E99C12C3F@microso
ft.com>
<eetHpJE$FHA.1988@TK2MSFTNGP12.phx.gbl>
<9C657D31-EA77-4B69-866B- 841100DAE9F7@microso
ft.com>
<#k0D1mE$FHA.2520@TK2MSFTNGP15.phx.gbl>
>Subject: Re: AS 2005 HTTP access with Basic Authentication
>Date: Thu, 8 Dec 2005 14:59:01 -0800
>Lines: 102
>Message-ID: <87BEBCE0-C185-43AB-9114- 615563011FA1@microso
ft.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 7bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.sqlserver.olap
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.sqlserver.olap:65302
>X-Tomcat-NG: microsoft.public.sqlserver.olap
>
>I'm using OWC 11 as the app, hosted inside sharepoint site. prompt=1 does
>nothing. I've tried changing every IE setting that I could think of to
see
>if that had anything to do with it, but no luck.
>
>
>Scott
>
>"Edward Melomed [MSFT]" wrote:
>
provider as[color=darkred]
Connection[color=dar
kred]
rights.[color=darkred]
get[color=darkred]
it[color=darkred]
doesn't[color=darkre
d]
string[color=darkred
]
an[color=darkred]
know[color=darkred]
-[color=darkred]
authentication[color
=darkred]
doesn't[color=darkre
d]
for[color=darkred]
msmdsrv.ini[color=darkred]
ideas?[color=darkred]
>
| |
|
| Come on Edward, there are several posts on this newsgroup documenting that
HTTP with Basic Authentication doesn't work on AS2005.
I have a support incident open for 3 weeks and counting about this, and I
saw somebody else on this newsgroup with another support incident still open.
The issue is caused by OLEDB 9.0, who doesn't let the credentials pass from
IIS to AS2005.
It probably works on your own workstation because you are signed in as a
user that is known to the server, thus bypassing the basic authentication.
"Edward Melomed [MSFT]" wrote:
> Once you enabled the Basic Authentication you need to make sure you specify
> your credentials.
> You can do it ever by specifying "user" and "password" connection string
> properties in your connection string.
> Or you can add "prompt=1" to your connection string and you will get
> additional dialog asking for your credentials.
>
>
> Edward Melomed
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>
> "Scott Ivey" <iveys@online.nospam> wrote in message
> news:3B651890-487C-4A78-B1DB- 635E99C12C3F@microso
ft.com...
>
>
>
| |
| Edward Melomed [MSFT] 2005-12-09, 11:23 am |
| Hi Pat.
I was looking at your previous postings and it is bit hard to understand
what is going on in your situation.
When you are saying that you alreday authenticated to IIS , what does that
mean?
"Pat" <pat@online.nospam> wrote in message
news:8E504CDE-4FEA-436B-BD3C- 676D555B6345@microso
ft.com...[color=darkred]
> Come on Edward, there are several posts on this newsgroup documenting that
> HTTP with Basic Authentication doesn't work on AS2005.
> I have a support incident open for 3 weeks and counting about this, and I
> saw somebody else on this newsgroup with another support incident still
> open.
> The issue is caused by OLEDB 9.0, who doesn't let the credentials pass
> from
> IIS to AS2005.
> It probably works on your own workstation because you are signed in as a
> user that is known to the server, thus bypassing the basic authentication.
>
>
> "Edward Melomed [MSFT]" wrote:
>
| |
|
| It means that I have authenticated to IIS with basic authentication. When the
client navigates to the page containing the OWC control, IIS requests the
userID+pwd for basic authentication.
With AS2000 that's all you need. The subsequent connection from OWC to
AS2000 is done using this authentication token.
With AS2005, you're suggesting to add a "prompt=1" in the OWC connection
string. What happens is the following: User navigates to the page containing
the OWC control and IIS requests the userID+pwd for basic authentication, as
above.
When connecting OWC to AS2005 though, the prompt=1 causes you to enter your
userID+password once again. This means that the previous authentication to
IIS is completely bypassed.
You have to do that because OLEDB 9.0 and AS2005 are not able to work the
way OLEDB 8.0 and AS2000 did. They cannot use the IIS token.
In my opinion, this is the reason why you cannot connect to AS2005 from
Excel, whichever way you try (even the prompt=1 cheat doesn't help) unless
client and server are in the same domain.
"Edward Melomed [MSFT]" wrote:
> Hi Pat.
> I was looking at your previous postings and it is bit hard to understand
> what is going on in your situation.
> When you are saying that you alreday authenticated to IIS , what does that
> mean?
>
>
> "Pat" <pat@online.nospam> wrote in message
> news:8E504CDE-4FEA-436B-BD3C- 676D555B6345@microso
ft.com...
>
>
>
| |
| Scott Ivey 2005-12-12, 11:23 am |
| Pat - I agree with you that its a bigger problem. My solution worked fine
before I upgraded to AS2005. My current problem is that OWC hosted in my
sharepoint 2.0 site will now NEVER prompt for a username & password, even if
I include prompt=1. My sharepoint server & AS/HTTP server have different
domain names, so it should always prompt for the cross domain data request
anyway, but never does. It always did this with AS2000 before I upgraded to
2005, but since the upgrade, it never prompts. I'm able to use a hard-wired
username & password in the connect string, but would prefer to have it prompt
the user so that I can use their own username & password instead of a single
shared one. Another thing worth noting, is that like pat said, if I'm in the
domain or connected to the server via VPN, it will work, but when I'm not
connected via any other means than my IE browser to the sharepoint site,
nothing works at all.
I've had an open support ticket on this for a week now, and have had a hard
time convincing any of the support techs that I've talked to that this is a
problem for me. I keep getting handed around from group to group inside
microsoft, and everyone says that its the next guys problem. I'm feeling
like my $245 for this incident hasn't been well spent.
Scott
"Pat" wrote:
[color=darkred]
> It means that I have authenticated to IIS with basic authentication. When the
> client navigates to the page containing the OWC control, IIS requests the
> userID+pwd for basic authentication.
> With AS2000 that's all you need. The subsequent connection from OWC to
> AS2000 is done using this authentication token.
>
> With AS2005, you're suggesting to add a "prompt=1" in the OWC connection
> string. What happens is the following: User navigates to the page containing
> the OWC control and IIS requests the userID+pwd for basic authentication, as
> above.
> When connecting OWC to AS2005 though, the prompt=1 causes you to enter your
> userID+password once again. This means that the previous authentication to
> IIS is completely bypassed.
> You have to do that because OLEDB 9.0 and AS2005 are not able to work the
> way OLEDB 8.0 and AS2000 did. They cannot use the IIS token.
>
> In my opinion, this is the reason why you cannot connect to AS2005 from
> Excel, whichever way you try (even the prompt=1 cheat doesn't help) unless
> client and server are in the same domain.
>
>
> "Edward Melomed [MSFT]" wrote:
>
| |
| Akshai Mirchandani [MS] 2005-12-14, 8:25 pm |
| Re-posting part of my other posting to this thread:
2. If you are inside Internet Explorer and browse to a web page and specify
Basic authentication credentials. Then the web page inside IE tries to
connect to an AS server over HTTP in the same "realm" -- for AS 2000, this
would work without demanding the basic authentication credentials again. But
in AS 2005, you are required to re-submit the credentials a second time.
There is a good technical explanation for this which I won't go into, but
the AS 2000 way was a little unsafe and it's probably a good thing that this
doesn't work today...
Since there seems to be a big issue for you folks let me try to go into a
more detailed explanation here -- hopefully that will clear this up a
little.
AS 2000's PTS (msolap80) used WinInet to connect to the server over HTTP. AS
2005 uses a newer API called WinHttp -- this newer API is safe for servers
and is in general a much better API to use. Unfortunately the impact appears
to be this:
- Internet Explorer also uses WinInet
- When PTS 8.0 ran within Internet Explorer, it's WinInet connections were
automatically re-using the credentials that Internet Explorer had obtained
when connecting to the same realm
- Since PTS 8.0 doesn't use WinInet, it doesn't inherit those same
credentials and it requires you to re-authenticate the user
This is still under investigation and it's possible that we're mistaken
about this behavior -- but there is a high likelihood that this is the
cause.
Unfortunately this isn't something that can be easily worked around -- the
WinInet credentials may not be available outside WinInet. Additionally,
since these components are not owned by the SQL Server group, it will take
some time to find the right people to investigate and its possible there
isn't a solution...
If you get in touch with your support contact again, please send them my
name and ask them to get in touch with me if they have any questions.
Thanks,
Akshai
--
This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Scott Ivey" <iveys@online.nospam> wrote in message
news:251D57D7-02D7-469C-A137- EE5A00063120@microso
ft.com...[color=darkred]
> Pat - I agree with you that its a bigger problem. My solution worked fine
> before I upgraded to AS2005. My current problem is that OWC hosted in my
> sharepoint 2.0 site will now NEVER prompt for a username & password, even
> if
> I include prompt=1. My sharepoint server & AS/HTTP server have different
> domain names, so it should always prompt for the cross domain data request
> anyway, but never does. It always did this with AS2000 before I upgraded
> to
> 2005, but since the upgrade, it never prompts. I'm able to use a
> hard-wired
> username & password in the connect string, but would prefer to have it
> prompt
> the user so that I can use their own username & password instead of a
> single
> shared one. Another thing worth noting, is that like pat said, if I'm in
> the
> domain or connected to the server via VPN, it will work, but when I'm not
> connected via any other means than my IE browser to the sharepoint site,
> nothing works at all.
>
> I've had an open support ticket on this for a week now, and have had a
> hard
> time convincing any of the support techs that I've talked to that this is
> a
> problem for me. I keep getting handed around from group to group inside
> microsoft, and everyone says that its the next guys problem. I'm feeling
> like my $245 for this incident hasn't been well spent.
>
> Scott
>
> "Pat" wrote:
>
| |
|
| Thanks for the clarification. So the problem seems to be at the client rather
than at the server as I was assuming.
In any case, This is also an Excel issue, not just IE.
Leaving aside the cause of the problem, users are expecting to sign-in once
to the server and then to carry on working without having to sign-in again.
This used to work with AS2000, and we need to find a solution for it to work
with AS2005 too.
Please refer to my reply to your other post for technical details, and
thanks for looking into this issue.
"Akshai Mirchandani [MS]" wrote:
> Re-posting part of my other posting to this thread:
>
> 2. If you are inside Internet Explorer and browse to a web page and specify
> Basic authentication credentials. Then the web page inside IE tries to
> connect to an AS server over HTTP in the same "realm" -- for AS 2000, this
> would work without demanding the basic authentication credentials again. But
> in AS 2005, you are required to re-submit the credentials a second time.
> There is a good technical explanation for this which I won't go into, but
> the AS 2000 way was a little unsafe and it's probably a good thing that this
> doesn't work today...
>
> Since there seems to be a big issue for you folks let me try to go into a
> more detailed explanation here -- hopefully that will clear this up a
> little.
>
> AS 2000's PTS (msolap80) used WinInet to connect to the server over HTTP. AS
> 2005 uses a newer API called WinHttp -- this newer API is safe for servers
> and is in general a much better API to use. Unfortunately the impact appears
> to be this:
> - Internet Explorer also uses WinInet
> - When PTS 8.0 ran within Internet Explorer, it's WinInet connections were
> automatically re-using the credentials that Internet Explorer had obtained
> when connecting to the same realm
> - Since PTS 8.0 doesn't use WinInet, it doesn't inherit those same
> credentials and it requires you to re-authenticate the user
>
> This is still under investigation and it's possible that we're mistaken
> about this behavior -- but there is a high likelihood that this is the
> cause.
>
> Unfortunately this isn't something that can be easily worked around -- the
> WinInet credentials may not be available outside WinInet. Additionally,
> since these components are not owned by the SQL Server group, it will take
> some time to find the right people to investigate and its possible there
> isn't a solution...
>
> If you get in touch with your support contact again, please send them my
> name and ask them to get in touch with me if they have any questions.
>
> Thanks,
> Akshai
> --
> This posting is provided "AS IS" with no warranties, and confers no rights
> Please do not send email directly to this alias. This alias is for newsgroup
> purposes only.
>
> "Scott Ivey" <iveys@online.nospam> wrote in message
> news:251D57D7-02D7-469C-A137- EE5A00063120@microso
ft.com...
>
>
>
| |
| Scott Ivey 2005-12-15, 9:23 am |
| My users are NEVER prompted to sign in. This would be at least workable if
they were prompted to sign in EVERY time like Akshai suggests should be the
case.
Akshai - I'll forward your post to the engineers I'm working with. I
finally got transferred to engineers on Wednesday that know what they were
talking about. Within minutes of me explaining my problem, they were talking
about the wininet vs winhttp issues, rather than trying to tell me its
someone elses problem :)
Thanks,
Scott
"Akshai Mirchandani [MS]" wrote:
> Re-posting part of my other posting to this thread:
>
> 2. If you are inside Internet Explorer and browse to a web page and specify
> Basic authentication credentials. Then the web page inside IE tries to
> connect to an AS server over HTTP in the same "realm" -- for AS 2000, this
> would work without demanding the basic authentication credentials again. But
> in AS 2005, you are required to re-submit the credentials a second time.
> There is a good technical explanation for this which I won't go into, but
> the AS 2000 way was a little unsafe and it's probably a good thing that this
> doesn't work today...
>
> Since there seems to be a big issue for you folks let me try to go into a
> more detailed explanation here -- hopefully that will clear this up a
> little.
>
> AS 2000's PTS (msolap80) used WinInet to connect to the server over HTTP. AS
> 2005 uses a newer API called WinHttp -- this newer API is safe for servers
> and is in general a much better API to use. Unfortunately the impact appears
> to be this:
> - Internet Explorer also uses WinInet
> - When PTS 8.0 ran within Internet Explorer, it's WinInet connections were
> automatically re-using the credentials that Internet Explorer had obtained
> when connecting to the same realm
> - Since PTS 8.0 doesn't use WinInet, it doesn't inherit those same
> credentials and it requires you to re-authenticate the user
>
> This is still under investigation and it's possible that we're mistaken
> about this behavior -- but there is a high likelihood that this is the
> cause.
>
> Unfortunately this isn't something that can be easily worked around -- the
> WinInet credentials may not be available outside WinInet. Additionally,
> since these components are not owned by the SQL Server group, it will take
> some time to find the right people to investigate and its possible there
> isn't a solution...
>
> If you get in touch with your support contact again, please send them my
> name and ask them to get in touch with me if they have any questions.
>
> Thanks,
> Akshai
> --
> This posting is provided "AS IS" with no warranties, and confers no rights
> Please do not send email directly to this alias. This alias is for newsgroup
> purposes only.
>
> "Scott Ivey" <iveys@online.nospam> wrote in message
> news:251D57D7-02D7-469C-A137- EE5A00063120@microso
ft.com...
>
>
>
| |
| Akshai Mirchandani [MS] 2005-12-20, 3:24 am |
| As per our discussions so far with the WinHttp team this will take time to
solve on their end. In the interim we're investigating other options, but
please have patience for this issue.
Thanks,
Akshai
--
This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Pat" <pat@online.nospam> wrote in message
news:6853A86A-DABF-4057-BB3B- C543E2FF2D16@microso
ft.com...[color=darkred]
> Thanks for the clarification. So the problem seems to be at the client
> rather
> than at the server as I was assuming.
> In any case, This is also an Excel issue, not just IE.
>
> Leaving aside the cause of the problem, users are expecting to sign-in
> once
> to the server and then to carry on working without having to sign-in
> again.
> This used to work with AS2000, and we need to find a solution for it to
> work
> with AS2005 too.
>
> Please refer to my reply to your other post for technical details, and
> thanks for looking into this issue.
>
> "Akshai Mirchandani [MS]" wrote:
>
| |
| Scott Ivey 2005-12-21, 9:23 am |
| Thanks Akshai. The engineer on my case (John Desh) mentioned that he had
talked to you about this as well. I'm anxious for a fix, but can live with
the workaround in the meantime.
Scott Ivey
"Akshai Mirchandani [MS]" wrote:
[color=darkred]
> As per our discussions so far with the WinHttp team this will take time to
> solve on their end. In the interim we're investigating other options, but
> please have patience for this issue.
>
> Thanks,
> Akshai
> --
> This posting is provided "AS IS" with no warranties, and confers no rights
> Please do not send email directly to this alias. This alias is for newsgroup
> purposes only.
>
> "Pat" <pat@online.nospam> wrote in message
> news:6853A86A-DABF-4057-BB3B- C543E2FF2D16@microso
ft.com...
|
|
|
|
|