APM Rewrite and MS Sharepoint

This bypass thing is a product of the APM portal function. There is no bypass list, that I'm aware of, when applying an access policy directly to a SharePoint VIP. The access policy does whatever you need it to do for client side authentication, and applies a server side SSO. No resource assignment agent, no webtop. One of the biggest issues with SharePoint document editing under APM is the need for a persistent session cookie, otherwise document editing should work just fine.

Hmm... I will need to dig deeper... Perhaps I'm doing the iAPP incorrectly. I can run the iAPP, enter all the values and when I try to connect, I get the IIS screen instead of a sharepoint screen. In order to get this to work, I take the iAPP out of strict state and add portal access for the sharepoint server. I'll start digging deeper tomorrow... Thanks, Danny

I've been working on the same thing. I know the rewrite would be a problem for SharePoint so I opt not to use it. I have publish my web app directly with an access profile but I'm having trouble opening and editing document in Office. I'm trying the persist cookie but the last thing that I also have in the works is multi-domain SSO. I have a couple of web applications and I would like to SSO into. One of the reason for the cookie based persist because MS Office opens a different connection back to the server.

One of the reason for the cookie based persist because MS Office opens a different connection back to the server.

That's absolutely at least the primary reason for requiring persistent APM session cookies with SharePoint. Because APM is cookie based, and because documents are generally opened in an application separate from the browser, you need a persistent (file-based) cookie that the app can access, something that's outside of browser memory. It's also safe to say, that there are exceptions to this rule, that some tools can use the browser's in-memory session cookie, and some that can't even use the file-based cookie. It tends to depend on which SharePoint version, which Office product is installed on the client (if any) and/or which app is used to open documents, and what day of the month it is...

Ok, finally figured out why I was getting the IIS screen. According to my Sharepoint guy, if I connect using the FQDN of the server, in Sharepoint there is a table that will recognize this and return the default page. If I enter only the IP address, I will only get the top level page (IIS) and not the sharepoint page. This, according to my SP guy is because there is no entry for IP only in the SP table. Looking at the iAPP, I tried to enter the FQDN and it was converted to IP address before adding to config.

This explanation sound valid?

Regards,

Danny

Finally got the iAPP working. I wound up working with the SP guy to get the Alternate Access mappings corrected and now all seems to work just fine.. Sweet... However, in order to get this working I had to use the iAPP to create my configs. One thing I noticed is that the iAPP does not use rewrite, which was causing my SP issues all along. That being said, is it possible to modify this iAPP install to provide a Webtop?

Thanks, Danny

So I'm assuming you need a webtop so that you can have multiple "portal-like" options for the user, yes? If so, you may consider doing a webtop link and pointing it to your iApp-based SharePoint VIP.

Yes, that's what I am after. "Portal-like" options. Let me dig...

I know it's been a while... But I still need to be able to do this... How do I create a webtop link for my iAPP VIP?

Thanks, dg