Intranet/Internet and Reporting Services

We have a situation where we are going to have our IIS server with two NIC
cards. One for the internet and one for the intranet. We are planning to have
our SQL Server connected to the IIS server via the intranet.
My question is... if a user on the internet requests a report and we render
it programmatically via visual basic/visual C# (Using a reporting services
object in ASP) on the web will they have access to the report even though
they do not have direct access to the SQL Reporting Services server? Will I
be able to take what is returned to that object and display it on the
Intranet?
TIA,
PatrickYes. You can use the Response.BinaryWrite() method to direct the report
content to a webform or ASP page. There are limitations, however, with
images and interactive report features when using this approach.
"Patrick Allmond" <PatrickAllmond@.discussions.microsoft.com> wrote in
message news:EDC55557-ECE5-4F21-B07B-583896BDE7D5@.microsoft.com...
> We have a situation where we are going to have our IIS server with two NIC
> cards. One for the internet and one for the intranet. We are planning to
> have
> our SQL Server connected to the IIS server via the intranet.
> My question is... if a user on the internet requests a report and we
> render
> it programmatically via visual basic/visual C# (Using a reporting services
> object in ASP) on the web will they have access to the report even though
> they do not have direct access to the SQL Reporting Services server? Will
> I
> be able to take what is returned to that object and display it on the
> Intranet?
> TIA,
> Patrick
>

Intranet, windows authentication, Sql Server Login Failed for user (null)

Hi--

I am building an intRAnet website using windows authentication for website access and SQL Server access ( Trusted_Connection = true ).

In IIS I have these settings:

Allow Anonymous = unchecked (false)Windows Authentication = Checked (true)Digest windows = checked (true)

In my Web.Config file:

authentication="windows"impersonate="true"allowusers="*"

When I pull up the page these are my credentials:

Security.Principal.Windows: mydomain\myuserid (this is correct what it shows on my page)

Me.User.Identity: mydomain\myuserid (this is correct what it shows on my page)

Threading.currentThread.currentUser mydomain\myuserid (this is correct what it shows on my page)

So the ASP.NET page recognizes it is me and my domain. However, when i click a button to pull some data from a database I get the error message: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.

My data access on SQL Server works fine. The weird thing is when I debug on my machine it pulls data fine. but when I copy the files to the windows 2003 server it doesn't work.

Do i have to do something with delegation?

some guys and i did some research and we think that kerberos delegation is not enabled on our domain in active directory.

When i take off digest, and select basic authentication the credentials pass...but i don't want that.

Internet Merge Replication IIS

Maybe I am missing something here, but it seems like the point of doing Merge Replication via IIS is so that you do not have to expose your DB server directly to the internet (i.e. all your clients), rather you expose a webserver to the internet and the webserver handles the replication keeping your DB server closed to direct internet access and thus keeping it more secure.

However, to set up Internet Merge Replication using IIS a client has to have direct internet access to the DB server as a stored procedure needs to be run on the publisher.

So Internet Merge Replciation using IIS makes it so your DB does not have to be directly exposed to the internet except your db needs to be exposed directly to the internet so every client can execute a stored procedure against it. How does this make sense? Yeah, I can write a webservice or something that gets the SP from the client and executes it against my db server but why should I have to? Why isn't the dll that the "Configure Web Synchronization" wizard puts into place capable of doing this?

Using web sync not only "hide" your sql server from the client, but also extends the merge replication to devices as well as PCs in anywhere that has the internet access. the later is actually the main reason to have this new sync type.

Sure, one can write their own web services to do the sync ( in fact, I believe there are some companies doing that already ), but this will not fully utilize the merge replication's functionalities to the web client subscriptions as it was to the fully connected subscriptions.

hence, the "Configure web synchronization" wizard means to provide some walk throguh steps to help users to set up the IIS server for replication and not to intend to setup the webservices.

thanks

Yunwen

|||

Thank you for your reply, but your reply...parts don't make sense and other parts don't answer what I asked.

>> but also extends the merge replication to devices as well as PCs in anywhere that has the internet access. the later is actually the main reason to have this new sync type.

That is NOT the "main reason" of doing web sync via IIS. Since for a client to do merge synching offsite, they have to have internet access to the sql server location, synching could be accomplished quite nicely without IIS by merely poking the appropriate holes in your firewall to allow the needed direct sql connections to be made. Thus IIS is not what facilitates merge synching over the internet. It still seems to me that the ONLY point of doing merge replication via IIS is to hide your SQL server from direct internet access.

>>Sure, one can write their own web services to do the sync

I never said this. What I said was that to set up Merge replication a client needed direct access to a sql server because a SP (Stored Procedure) has to be run against the Publisher that registeres the subscriber with the publisher. If you are using IIS to accomplish your merge replication, then you do not have your sql server directly exposed to the internet which makes it rather hard for your subscriber to connect directly to the publisher to execute a SP. What I said was that I could write a Webservice that could facilitate the subscriber sending the SP to the publisher but that I shouldn't have to as the replisapi.dll should be doing that. I said nothing about writing a webservice to do the sync, just that as things stand now I would have to write a webservice to facilitate setting up the sync.

So again, it seems like the point of using IIS to do merge replication is to hide your SQL Server publisher from the internet. However, part of setting up a subscriber involves running a SP (Stored Procedure) against the SQL Server Publisher. If your SQL Server publisher is hidden from the internet, it makes it rather impossible for your subscriber to connect to it to run a SP against it. It seems that currently the only work around is to make your own webservice that can access the SP arguments from the subscriber and run the proper SP with the proper arguments against your publisher for you. It seems sort of silly that you would have to set that up yourself, that MS hasn't built that in to something that already exists.

The situation is analguous to the Exchange RPC over HTTPS problem that occured when Office 2003 first came out. RPC over HTTPS allows Outlook to run against an Exchange server without having to have direct port 135-139 access. However in order to set up RPC over HTTPS your computer FIRST had to be able to connect directly to Exchange on ports 135-139 (which was a problem for me since I use Comcast and Comcast blocks these ports). The only work around was to lug my computer into the office, put it on a lan with the exchange server, setup RPC over HTTPS, then take it back home.) MS has since fixed this problem. However, this seems like the exact same problem. Doing merge replication via IIS makes it so that clients do not have to connect directly to the SQL Server, however to initially set up each client, that client has to connect directly to the SQL Server. Is there a way around this?

Thank you

|||

Many people may not have ability to connect to publisher directly through port 1433. That is one of the main motivation to support https (port 443) replication. IIS server is needed to understand the https protocol.

|||

Yes, that is right along the lines of what I have been saying.

Why is this so hard to understand? I will try to make it simple.

I have a sql server that is acting as a publisher. This publisher is not directly accessable via the internet. I have set up Merge replication using IIS and https on a server running IIS. The IIS server is accessable to the internet on ports 80 and 443. Ok? Simple enough.

I want to connect a subscriber to this publisher. The subscriber is somewhere on the internet. In order for the subscriber to successfully set up its subscription, it needs to execute the Stored Procedure named "sp_addmergesubscription" ON THE PUBLISHER!

As you so aptly pointed out "Many people may not have ability to connect to publisher directly through port 1433" that being the case, how then is a subscriber supposed to run the stored procedure "sp_addmergesubscription" on the publisher?

|||

You have two choices:

1. Add the subscription at the publisher before subscriber connects. Meaning an administrator at the publisher will need to add this information, not the subscriber since the subscriber does not have access.

2. Connect as an anonymous subscriber. Meaning if subscriber cannot have their subscription added to the publication, then connect as an anonymous subscriber, which will add the info for you on your first connect.

Internet Information Services (IIS) 5.0 Manager

I need to get hold of a website to download Internet
Information Services (IIS) 5.0 Manager. Can anyone help?
v6 cannot do what I need it for.Is this what you need?
308169 HOW TO: Remotely Administer Internet Information Services 5.0 in
Windows
http://support.microsoft.com/?id=308169
If that's not the information you were asking for, try posting on an IIS
newsgroup.
Cindy Gross, MCDBA, MCSE
http://cindygross.tripod.com
This posting is provided "AS IS" with no warranties, and confers no rights.