A2010 And Sharepoint Cals

#1

I'm still trying to wrap my head around the A2010, Web publishing apps,
and Sharepoint CALS.

If I upload the datafiles to a Sharepoint site as the backend and
distribute a local copy of the app (not a web app), either retail or
runtime, are you limited to the number of users that can access that
data based on the number of licenses one has on Sharepoint?

When one connects to the local app does one supply a Sharepoint pw? Or
does the app seamlessly link to the backend as a typical app linking to
a backend on a file server>

Regarding a web app. Let's say we have a timecard program. There are a
hundred employees. They need to punch in for work, punch out for lunch,
punch in from return from lunch, and punch out going home. I noticed
during Beta test and looking at the templates and they had a login form.
Is the login specific to Sharepoint or to the application? Do they
need to specify to logins? What If I had 5 licenses; user1...user5. Do
the users need to log in as a specific user or can the app determine who
is logged in and which license is available for punching in or out? I
guess one analogy would be to call into a dial-up internet line. If the
line is busy it just rolls down to the next number until it finds a free
line. If none are available the line is busy.

How does Sharepoint know who is on? Could one log in, punch in or out
and automatically close the app, freeing up that license for another person?

#2

On 8/18/10 11:39 AM, Salad wrote:

Quote:

I'm still trying to wrap my head around the A2010, Web publishing apps,
and Sharepoint CALS.

Here's a link to information on SharePoint licensing.

http://sharepoint.microsoft.com/en-u...g-Details.aspx

The thing we need to remember is that Access Services is considered an
enterprise feature so we need a Enterprise CAL.

Furthermore, CAL can be purchased either per-user or per-device.

Next, note that there is a separate licensing structure for external
access but in this context, the licensing is restricted to certain
features and therefore still requires an Enterprise CAL to grant the
external users access to any enterprise features, including Access
Services. So even though there may be different licensing for internal
and external access, when we're talking about Access Services, we need
Enterprise CAL either way.

Quote:

If I upload the datafiles to a Sharepoint site as the backend and
distribute a local copy of the app (not a web app), either retail or
runtime, are you limited to the number of users that can access that
data based on the number of licenses one has on Sharepoint?

Depends on whether you bought a per-user or per-device CAL. I would
imagine with a per-device CAL, you theoretically can allow more than one
user to gain the access but they'd have to use the same device. That
would work OK for say, a workstation shared by different users that
comes/leaves at different time of the day.

Quote:

When one connects to the local app does one supply a Sharepoint pw? Or
does the app seamlessly link to the backend as a typical app linking to
a backend on a file server

By default, anonymous access is not enabled. So, regardless of how one
connects to SharePoint, whether in a web browser or from Access client,
there will be a prompt to log in. I've also found that anonymous access
also does not work inside a client and log in is thus still required
even if anonymous access was enabled.

I'm not sure I understand your 2nd question -- I'm thinking we're
talking web databases here, in which case, the tables are actually
SharePoint lists and thus works like any other SharePoint lists and thus
requires a login to access the lists (unless anonymous access was
granted and one is using web browser).

Quote:

Regarding a web app. Let's say we have a timecard program. There are a
hundred employees. They need to punch in for work, punch out for lunch,
punch in from return from lunch, and punch out going home. I noticed
during Beta test and looking at the templates and they had a login form.
Is the login specific to Sharepoint or to the application? Do they need
to specify to logins? What If I had 5 licenses; user1...user5. Do the
users need to log in as a specific user or can the app determine who is
logged in and which license is available for punching in or out? I guess
one analogy would be to call into a dial-up internet line. If the line
is busy it just rolls down to the next number until it finds a free
line. If none are available the line is busy.

How does Sharepoint know who is on? Could one log in, punch in or out
and automatically close the app, freeing up that license for another
person?

As mentioned above, if you bought a per-device CAL, you could in theory
share the same license among different users if they go to the same
device. OTOH, a per-user CAL means one doesn't have to be chained to a
certain workstation. Different strokes for different folks and all that.

#3

Banana wrote:

Quote:

On 8/18/10 11:39 AM, Salad wrote:

I'm still trying to wrap my head around the A2010, Web publishing apps,
and Sharepoint CALS.

Here's a link to information on SharePoint licensing.

http://sharepoint.microsoft.com/en-u...g-Details.aspx

The thing we need to remember is that Access Services is considered an
enterprise feature so we need a Enterprise CAL.

Furthermore, CAL can be purchased either per-user or per-device.

Next, note that there is a separate licensing structure for external
access but in this context, the licensing is restricted to certain
features and therefore still requires an Enterprise CAL to grant the
external users access to any enterprise features, including Access
Services. So even though there may be different licensing for internal
and external access, when we're talking about Access Services, we need
Enterprise CAL either way.

If I upload the datafiles to a Sharepoint site as the backend and
distribute a local copy of the app (not a web app), either retail or
runtime, are you limited to the number of users that can access that
data based on the number of licenses one has on Sharepoint?

Depends on whether you bought a per-user or per-device CAL. I would
imagine with a per-device CAL, you theoretically can allow more than one
user to gain the access but they'd have to use the same device. That
would work OK for say, a workstation shared by different users that
comes/leaves at different time of the day.

For a local app, if I understand correctly, there'd be no reason then to
have the backend on Sharepoint except for bragging rights. If there's
no collaboration features with other files that may reside on Sharepoint
like a spreadsheet or Word doc, there's even less.

Quote:

When one connects to the local app does one supply a Sharepoint pw? Or
does the app seamlessly link to the backend as a typical app linking to
a backend on a file server

By default, anonymous access is not enabled. So, regardless of how one
connects to SharePoint, whether in a web browser or from Access client,
there will be a prompt to log in. I've also found that anonymous access
also does not work inside a client and log in is thus still required
even if anonymous access was enabled.

It appears you need a license per user whether or not the user was on it
for 1 minute, all day, or never but there is a possibility.

Quote:

I'm not sure I understand your 2nd question -- I'm thinking we're
talking web databases here, in which case, the tables are actually
SharePoint lists and thus works like any other SharePoint lists and thus
requires a login to access the lists (unless anonymous access was
granted and one is using web browser).

Well, yes and no. I figured one could have a backend on Sharepoint or a
backend as normal. Does anyone really care where the data resides as
long as you can access it? I guess there is really no need to have
Sharepoint be the backend for a desktop app unless one likes to spend
money for no reason. I guess I had this concept of some users sitting
in an office doing their work and some people accessing data on the web.
In that case I guess Sharepoint could be the backend as a person on
the web would need constant updates in order to be current.

Quote:

Regarding a web app. Let's say we have a timecard program. There are a
hundred employees. They need to punch in for work, punch out for lunch,
punch in from return from lunch, and punch out going home. I noticed
during Beta test and looking at the templates and they had a login form.
Is the login specific to Sharepoint or to the application? Do they need
to specify to logins? What If I had 5 licenses; user1...user5. Do the
users need to log in as a specific user or can the app determine who is
logged in and which license is available for punching in or out? I guess
one analogy would be to call into a dial-up internet line. If the line
is busy it just rolls down to the next number until it finds a free
line. If none are available the line is busy.

How does Sharepoint know who is on? Could one log in, punch in or out
and automatically close the app, freeing up that license for another
person?

As mentioned above, if you bought a per-device CAL, you could in theory
share the same license among different users if they go to the same
device. OTOH, a per-user CAL means one doesn't have to be chained to a
certain workstation. Different strokes for different folks and all that.

I think the bottom line is...no matter what it is going to be costly.

#4

On 8/18/10 1:00 PM, Salad wrote:

Quote:

For a local app, if I understand correctly, there'd be no reason then to
have the backend on Sharepoint except for bragging rights. If there's no
collaboration features with other files that may reside on Sharepoint
like a spreadsheet or Word doc, there's even less.

[...]

Quote:

Well, yes and no. I figured one could have a backend on Sharepoint or a
backend as normal. Does anyone really care where the data resides as
long as you can access it? I guess there is really no need to have
Sharepoint be the backend for a desktop app unless one likes to spend
money for no reason. I guess I had this concept of some users sitting in
an office doing their work and some people accessing data on the web. In
that case I guess Sharepoint could be the backend as a person on the web
would need constant updates in order to be current.

Well, there is one other reason why a desktop app would benefit from
using SharePoint as a backend: the ability to work offline and use a
local cache. IOW, this is the replacement to old Jet Replication but
without the complex set-up.

However, it should be noted that as long as that is the only thing we
need to do, you actually don't have to have Enterprise feature to use
the ability to work offline. You only need SharePoint Foundation, which
is nominally free if one has the Windows Server products and if I
understand the licensing correctly, does not require any CALs.

That is basically the only distinguishing feature setting the SharePoint
List as a linked table apart from the rest of ODBC-linked tables. So, if
you didn't need the ability to disconnect and work without a connection
(e.g. the good old "traveling salesman" scenario), then there's no
reason to have any edition of SharePoint for the Access solution (that
is not to say that it could be justified for different problems outside
of Access for a given company but I'm guessing you're not concerned
about that anyway)

Quote:

I think the bottom line is...no matter what it is going to be costly.

Well, if one only needed either ability to use SharePoint lists as a
linked table for client apps or a means of distributing Access files, I
would think the pricing will quite be different from the ability to
access the same data inside a web browser.

#5

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4C6C2DE4.8030204 (AT) Republic (DOT) com:

Quote:

The thing we need to remember is that Access Services is
considered an enterprise feature so we need a Enterprise CAL.

But the scenario Salad described did not depend on Access Services
at all, just plain-jane low-level Sharepoint with no bells and
whistles.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#6

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:Sq-dnYr9H4ictPHRnZ2dnUVZ_tCdnZ2d (AT) earthlink (DOT) com:

Quote:

How does Sharepoint know who is on? Could one log in, punch in or
out and automatically close the app, freeing up that license for
another person?

How does SQL Server know who's logged on when you're using Windows
authentication? I don't know for a fact, but I'd expect the default
authentications to be via AD/domain logon.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#7

www.sharepointfields.com

Sharepoint Fields Package provides custom Sharepoint Fields.

History Column is a rich text column that tracks all editing posts
history and authors in a conversation manner. Each time user edits a
comment on task - new history record with comment, author and date is
added.

Master-detail lookup Column extends standard lookup with two and more
cascaded list dependencies.

Progress Column visualizes numeric data in progress-bar mode. Common
scenarios when Progress Column is usable are projects, activities ,
tasks or sales lists that have 'Progress' or 'Compete state' fields.

Visual Choice column displays choice column value via color or image
associated with a choice.

LinkImage column provides native 'Hyperlink with Image' column
support

www.sharepointfields.com