If you use Office 2013 and Office 365 license for one person, $6 per month, is there any authentication that web users need to use to access the web site you build with Access 2013/sharepoint? Can the $6 per month allow unlimited number of users to use the web site?
"BobAlston" wrote in message news:k6mu9a$edv$1@dont-email.me...
>If you use Office 2013 and Office 365 license for one person, $6 per month, >is there any authentication that web users need to use to access the web >site you build with Access 2013/sharepoint? Can the $6 per month allow >unlimited number of users to use the web site?
>Thanks
>bob
All users that hit the site MUST have a valid logon.
In fact I'm pretty hard pressed to think of any web based system in which some type of user logon is not required? In other words are you expecting to allow the wild Internet to update these tables attached to access forms?
Keep in mind that you can invite up to 50 users for free to the site, and they don't have to be an office 365 (or Live, hotmail) user id.
However they will have to associate e-mail with a live ID for this to work. (or already have a Hotmail or live id or a "onMicrosoft").
There is not an ability for anonymous users on 365.
In fact I just asked a question yesterday on this, and I'm going to cut and RE paste my response, since I cover several scenarios here:
===============
I am hard pressed to think of some kind of database on the web that everybody who comes to the site has able to make modifications to? Or even use?
So yes, at the end of the day for any user to utilize an Access application online they will have to logon to the site and as such have a valid sign on ID and valid permissions you given to them.
(I STRESS THE part YOU HAVE given to them).
You are of course able with office 365 able to invite for free up to 50 users without cost. In fact it is relatively recent that these users don't have to logon with a live ID either.
What this means is the user can login into your site with their existing e-mail ID. That logon can be yahoo, Gmail, or joe.Ap...@apple.com.
However they will have to go through the process of associating their logon with a live ID for this to work.
I am not sure if you've ever used this new thing called the Internet? So using this site here, or office 365 (or Google docs) or in fact just ABOUT ANY site where there is some type of database content and system I would be hard pressed to imagine any of those sites not requiring some type of logon?
Unless you're hosting your own server, I don't believe any type of anonymous logon system can be used.
So at the end of the day you can invite users to your site. As a general note such users will require a live id (Hotmail, 365 logon, onmicrosoft, live). And if they don't have a live id, then as noted those users can associate their existing logon with a live ID. This would then allow them to log onto your site using their existing e-mail ID.
So they can use their corporate or non Microsoft email as a logon here (you have to invite them).
It does not clear to me if you're asking to users have to log into the site? (answer = yes, but that quite much expected).
In the case of AccessHosting? You will have to purchase + logon id's.
So there's no question that sitting down and working out the design of security and logon and issuing of user logons is an extremely important part of any web based development system.
In other words in your planning stages if you for example plan have 200 employees and want to use their EXISTING logons, then you can use what is called "federation". Federation's simply means that all of your internal corporate issue logons (active directory) will work on the web site, and if a new employees hired, or removed, or the change their password, it'll applied to the company logon, and they'll also instantly apply to the web logon.
I mean obviously if you have hundreds of employees, you don't want to have to manage this task of users since just the changing of passwords and managing of users could of itself become a fulltime job.
In fact in your planning stages and sitting down in terms of how uses security and logon IDs are to be issued and managed for the running of your web site is often not only the first step, but one of the MOST IMPORTANT steps that you will make. So this process can take considerable amounts of time on your part to ascertain what type of security and user authentication systems you're going to adopt for your web based technologies.
So for example if the website is not for your employees of your company, but as for external customers, then obviously choosing "federation" as your security model is not going to work.
And if you need some type of user self-sign up without interaction on your part? Then obviously even office 365 and the authentication and security methods provided would not be appropriate.
Last but not least:
Keep in mind that the typical Access database is setup in which you build a form that and that form is attached to a bunch of rows of data in a table. When you web enable such an application, the form will CONTINUE to EDIT the rows of data in the table. In other words the great ability of access to build forms that lets you edit all the data in the system will continue to work.
The problem is, that might not be your goal anymore! Access and in fact most Web based systems do not "OUT OF THE BLUE" or magically start restricting data to each individual user. You launch a form attached to a table, then they are editing all data.
So if you need restricted data to each individual user? Then you have to DESIGN this into your application. In fact if you've ever utilized user level security in an access application and you ALSO attempted to restrict data to each individual user, then you'll have an idea of the challenge you are up against. In other words user level security is a challenge, but the second part of developing an access application in which each logon user only sees their data is a far greater of a challenge.
Remember the web based tools do not magically implement this type of data restriction for each user. YOU the designer of the software that must implement such restrictions. If your existing application was never designed with such restrictions in mind, then it might not be appropriate for web based at all.
However delving in to the methods of security, methods of user authentication, and what type of Security Technologies you adopt for your website is far beyond that of a simple post in a newsgroup.
However, to summarize:
When using office 365, there's no anonymous users allowed.
When using office 365, there is no "self" signup ability for office 365 in which users can come to the site and self serve and build + create their own logons.
When using office 365, however you can invite users to the site and those uses as such don't have to logon with an office 365 logon id (but keep in mind the above mentioned association with alive ID is required).
If you are hosting your own SharePoint server that is running access web services, then you can adopt a system in which you issue user logons, and you can issue as many as you want for free. And no special type of association with any other system is required. This security and user authentication choice is called forms based authentication (FBA). This system ALSO ALLOWS SELF SERVE or user creating of logon id if you wish. (you have to set this up, but it is possible and thus users could in theory "sign up" to the web site without you having to issue logon's). So again depending on what type of system and user setup, the CORRECT kind of security system MUST be analyzed and adopted here. This is not different then determine if you need Access or SQL server, or if you are delivering pizza and if you need a gas or diesel truck.
So, the "kind" of users and security you need here is going to determine what system you will choose for your web site. I mean, if you just taking an existing Access form and converting it to the web, then likely you want all your internal users + their existing "logon" to work for this site (you would not want the wild internet to be able to use that database).
So, the kind of users, the kind of security, the kind of logons - all these questions have to be asked and analysed before you build any kind of web site.
I am a big fan of FBA (Forms based authentication), and this means that you don't have to use internal or what is called active directory users from your company. This also means the issuing of external user logons does not give these users permission to use your company network. And in fact these FBA users are a SEPARATE group of users and logons. And as noted FBA does open up the possibility of "self serve" or user created logons without you have to create or invite such users. FBA is not a option for office 365, but it is if you have your own SharePoint server.
However, as noted, we don't want to get into these areas of security and authentication methods in this forum since the subject is far too complex and far beyond that of being able to be answered in this post. So I can no more explain the details and nuances of relational database theory in this post, then that of attempting to explain the nuances and choices you have in regards to security and authentication of users.
However, at the end of the day, unless you're hosting your own SharePoint server, I don't believe you have a choice for self-signup options. The closest you have with office 365 is the ability to invite users to your site.
As noted, depending on the hosting choice you make, this choice will effect the type of users and logons you can use.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
>> If you use Office 2013 and Office 365 license for one person, $6 per
>> month, is there any authentication that web users need to use to
>> access the web site you build with Access 2013/sharepoint? Can the $6
>> per month allow unlimited number of users to use the web site?
>> Thanks
>> bob
> All users that hit the site MUST have a valid logon.
> In fact I'm pretty hard pressed to think of any web based system in
> which some type of user logon is not required? In other words are you
> expecting to allow the wild Internet to update these tables attached to
> access forms?
> Keep in mind that you can invite up to 50 users for free to the site,
> and they don't have to be an office 365 (or Live, hotmail) user id.
> However they will have to associate e-mail with a live ID for this to
> work. (or already have a Hotmail or live id or a "onMicrosoft").
> There is not an ability for anonymous users on 365.
> In fact I just asked a question yesterday on this, and I'm going to cut
> and RE paste my response, since I cover several scenarios here:
> ===============
> I am hard pressed to think of some kind of database on the web that
> everybody who comes to the site has able to make modifications to? Or
> even use?
> So yes, at the end of the day for any user to utilize an Access
> application online they will have to logon to the site and as such have
> a valid sign on ID and valid permissions you given to them.
> (I STRESS THE part YOU HAVE given to them).
> You are of course able with office 365 able to invite for free up to 50
> users without cost. In fact it is relatively recent that these users
> don't have to logon with a live ID either.
> What this means is the user can login into your site with their existing
> e-mail ID. That logon can be yahoo, Gmail, or joe.Ap...@apple.com.
> However they will have to go through the process of associating their
> logon with a live ID for this to work.
> I am not sure if you've ever used this new thing called the Internet? So
> using this site here, or office 365 (or Google docs) or in fact just
> ABOUT ANY site where there is some type of database content and system I
> would be hard pressed to imagine any of those sites not requiring some
> type of logon?
> Unless you're hosting your own server, I don't believe any type of
> anonymous logon system can be used.
> So at the end of the day you can invite users to your site. As a general
> note such users will require a live id (Hotmail, 365 logon, onmicrosoft,
> live). And if they don't have a live id, then as noted those users can
> associate their existing logon with a live ID. This would then allow
> them to log onto your site using their existing e-mail ID.
> So they can use their corporate or non Microsoft email as a logon here
> (you have to invite them).
> It does not clear to me if you're asking to users have to log into the
> site? (answer = yes, but that quite much expected).
> In the case of AccessHosting? You will have to purchase + logon id's.
> So there's no question that sitting down and working out the design of
> security and logon and issuing of user logons is an extremely important
> part of any web based development system.
> In other words in your planning stages if you for example plan have 200
> employees and want to use their EXISTING logons, then you can use what
> is called "federation". Federation's simply means that all of your
> internal corporate issue logons (active directory) will work on the web
> site, and if a new employees hired, or removed, or the change their
> password, it'll applied to the company logon, and they'll also instantly
> apply to the web logon.
> I mean obviously if you have hundreds of employees, you don't want to
> have to manage this task of users since just the changing of passwords
> and managing of users could of itself become a fulltime job.
> In fact in your planning stages and sitting down in terms of how uses
> security and logon IDs are to be issued and managed for the running of
> your web site is often not only the first step, but one of the MOST
> IMPORTANT steps that you will make. So this process can take
> considerable amounts of time on your part to ascertain what type of
> security and user authentication systems you're going to adopt for your
> web based technologies.
> So for example if the website is not for your employees of your company,
> but as for external customers, then obviously choosing "federation" as
> your security model is not going to work.
> And if you need some type of user self-sign up without interaction on
> your part? Then obviously even office 365 and the authentication and
> security methods provided would not be appropriate.
> Last but not least:
> Keep in mind that the typical Access database is setup in which you
> build a form that and that form is attached to a bunch of rows of data
> in a table. When you web enable such an application, the form will
> CONTINUE to EDIT the rows of data in the table. In other words the great
> ability of access to build forms that lets you edit all the data in the
> system will continue to work.
> The problem is, that might not be your goal anymore! Access and in fact
> most Web based systems do not "OUT OF THE BLUE" or magically start
> restricting data to each individual user. You launch a form attached to
> a table, then they are editing all data.
> So if you need restricted data to each individual user? Then you have to
> DESIGN this into your application. In fact if you've ever utilized user
> level security in an access application and you ALSO attempted to
> restrict data to each individual user, then you'll have an idea of the
> challenge you are up against. In other words user level security is a
> challenge, but the second part of developing an access application in
> which each logon user only sees their data is a far greater of a challenge.
> Remember the web based tools do not magically implement this type of
> data restriction for each user. YOU the designer of the software that
> must implement such restrictions. If your existing application was never
> designed with such restrictions in mind, then it might not be
> appropriate for web based at all.
> However delving in to the methods of security, methods of user
> authentication, and what type of Security Technologies you adopt for
> your website is far beyond that of a simple post in a newsgroup.
> However, to summarize:
> When using office 365, there's no anonymous users allowed.
> When using office 365, there is no "self" signup ability for office 365
> in which users can come to the site and self serve and build + create
> their own logons.
> When using office 365, however you can invite users to the site and
> those uses as such don't have to logon with an office 365 logon id (but
> keep in mind the above mentioned association with alive ID is required).
> If you are hosting your own SharePoint server that is running access web
> services, then you can adopt a system in which you issue user logons,
> and you can issue as many as you want for free. And no special type of
> association with any other system is required. This security and user
> authentication choice is called forms based authentication (FBA). This
> system ALSO ALLOWS SELF SERVE or user creating of logon id if you wish.
> (you have to set this up, but it is possible and thus users could in
> theory "sign up" to the web site without you having to issue logon's).
> So again depending on what type of system and user setup, the CORRECT
> kind of security system MUST be analyzed and adopted here. This is not
> different then determine if you need Access or SQL server, or if you are
> delivering pizza and if you need a gas or diesel truck.
> So, the "kind" of users and security you need here is going to determine
> what system you will choose for your web site. I mean, if you just
> taking an existing Access form and converting it to the web, then likely
> you want all your internal users + their existing "logon" to work for
> this site (you would not want the wild internet to be able to use that
> database).
> So, the kind of users, the kind of security, the kind of logons - all
> these questions have to be asked and analysed before you build any kind
> of web site.
> I am a big fan of FBA (Forms based authentication), and this means that
> you don't have to use internal or what is called active directory users
> from your company. This also means the issuing of external user logons
> does not give these users permission to use your company network. And in
> fact these FBA users are a SEPARATE group of users and logons. And as
> noted FBA does open up the possibility of "self serve" or user created
> logons without you have to create or invite such users. FBA is not a
> option for office 365, but it is if you have your own SharePoint server.
> However, as noted, we don't want to get into these areas of security and
> authentication methods in this forum since the subject is far too
> complex and far beyond that of being able to be answered in this post.
> So I can no more explain the details and nuances of relational database
> theory in this post, then that of attempting to explain the nuances and
> choices you have in regards to security and authentication of users.
> However, at the end of the day, unless you're hosting your own
> SharePoint server, I don't believe you have a choice for self-signup
> options. The closest you have with office 365 is the ability to invite
> users to your site.
> As noted, depending on the hosting choice you make, this choice
>>> If you use Office 2013 and Office 365 license for one person, $6 per
>>> month, is there any authentication that web users need to use to
>>> access the web site you build with Access 2013/sharepoint? Can the $6
>>> per month allow unlimited number of users to use the web site?
>>> Thanks
>>> bob
>> All users that hit the site MUST have a valid logon.
>> In fact I'm pretty hard pressed to think of any web based system in
>> which some type of user logon is not required? In other words are you
>> expecting to allow the wild Internet to update these tables attached to
>> access forms?
>> Keep in mind that you can invite up to 50 users for free to the site,
>> and they don't have to be an office 365 (or Live, hotmail) user id.
>> However they will have to associate e-mail with a live ID for this to
>> work. (or already have a Hotmail or live id or a "onMicrosoft").
>> There is not an ability for anonymous users on 365.
>> In fact I just asked a question yesterday on this, and I'm going to cut
>> and RE paste my response, since I cover several scenarios here:
>> ===============
>> I am hard pressed to think of some kind of database on the web that
>> everybody who comes to the site has able to make modifications to? Or
>> even use?
>> So yes, at the end of the day for any user to utilize an Access
>> application online they will have to logon to the site and as such have
>> a valid sign on ID and valid permissions you given to them.
>> (I STRESS THE part YOU HAVE given to them).
>> You are of course able with office 365 able to invite for free up to 50
>> users without cost. In fact it is relatively recent that these users
>> don't have to logon with a live ID either.
>> What this means is the user can login into your site with their existing
>> e-mail ID. That logon can be yahoo, Gmail, or joe.Ap...@apple.com.
>> However they will have to go through the process of associating their
>> logon with a live ID for this to work.
>> I am not sure if you've ever used this new thing called the Internet? So
>> using this site here, or office 365 (or Google docs) or in fact just
>> ABOUT ANY site where there is some type of database content and system I
>> would be hard pressed to imagine any of those sites not requiring some
>> type of logon?
>> Unless you're hosting your own server, I don't believe any type of
>> anonymous logon system can be used.
>> So at the end of the day you can invite users to your site. As a general
>> note such users will require a live id (Hotmail, 365 logon, onmicrosoft,
>> live). And if they don't have a live id, then as noted those users can
>> associate their existing logon with a live ID. This would then allow
>> them to log onto your site using their existing e-mail ID.
>> So they can use their corporate or non Microsoft email as a logon here
>> (you have to invite them).
>> It does not clear to me if you're asking to users have to log into the
>> site? (answer = yes, but that quite much expected).
>> In the case of AccessHosting? You will have to purchase + logon id's.
>> So there's no question that sitting down and working out the design of
>> security and logon and issuing of user logons is an extremely important
>> part of any web based development system.
>> In other words in your planning stages if you for example plan have 200
>> employees and want to use their EXISTING logons, then you can use what
>> is called "federation". Federation's simply means that all of your
>> internal corporate issue logons (active directory) will work on the web
>> site, and if a new employees hired, or removed, or the change their
>> password, it'll applied to the company logon, and they'll also instantly
>> apply to the web logon.
>> I mean obviously if you have hundreds of employees, you don't want to
>> have to manage this task of users since just the changing of passwords
>> and managing of users could of itself become a fulltime job.
>> In fact in your planning stages and sitting down in terms of how uses
>> security and logon IDs are to be issued and managed for the running of
>> your web site is often not only the first step, but one of the MOST
>> IMPORTANT steps that you will make. So this process can take
>> considerable amounts of time on your part to ascertain what type of
>> security and user authentication systems you're going to adopt for your
>> web based technologies.
>> So for example if the website is not for your employees of your company,
>> but as for external customers, then obviously choosing "federation" as
>> your security model is not going to work.
>> And if you need some type of user self-sign up without interaction on
>> your part? Then obviously even office 365 and the authentication and
>> security methods provided would not be appropriate.
>> Last but not least:
>> Keep in mind that the typical Access database is setup in which you
>> build a form that and that form is attached to a bunch of rows of data
>> in a table. When you web enable such an application, the form will
>> CONTINUE to EDIT the rows of data in the table. In other words the great
>> ability of access to build forms that lets you edit all the data in the
>> system will continue to work.
>> The problem is, that might not be your goal anymore! Access and in fact
>> most Web based systems do not "OUT OF THE BLUE" or magically start
>> restricting data to each individual user. You launch a form attached to
>> a table, then they are editing all data.
>> So if you need restricted data to each individual user? Then you have to
>> DESIGN this into your application. In fact if you've ever utilized user
>> level security in an access application and you ALSO attempted to
>> restrict data to each individual user, then you'll have an idea of the
>> challenge you are up against. In other words user level security is a
>> challenge, but the second part of developing an access application in
>> which each logon user only sees their data is a far greater of a
>> challenge.
>> Remember the web based tools do not magically implement this type of
>> data restriction for each user. YOU the designer of the software that
>> must implement such restrictions. If your existing application was never
>> designed with such restrictions in mind, then it might not be
>> appropriate for web based at all.
>> However delving in to the methods of security, methods of user
>> authentication, and what type of Security Technologies you adopt for
>> your website is far beyond that of a simple post in a newsgroup.
>> However, to summarize:
>> When using office 365, there's no anonymous users allowed.
>> When using office 365, there is no "self" signup ability for office 365
>> in which users can come to the site and self serve and build + create
>> their own logons.
>> When using office 365, however you can invite users to the site and
>> those uses as such don't have to logon with an office 365 logon id (but
>> keep in mind the above mentioned association with alive ID is required).
>> If you are hosting your own SharePoint server that is running access web
>> services, then you can adopt a system in which you issue user logons,
>> and you can issue as many as you want for free. And no special type of
>> association with any other system is required. This security and user
>> authentication choice is called forms based authentication (FBA). This
>> system ALSO ALLOWS SELF SERVE or user creating of logon id if you wish.
>> (you have to set this up, but it is possible and thus users could in
>> theory "sign up" to the web site without you having to issue logon's).
>> So again depending on what type of system and user setup, the CORRECT
>> kind of security system MUST be analyzed and adopted here. This is not
>> different then determine if you need Access or SQL server, or if you are
>> delivering pizza and if you need a gas or diesel truck.
>> So, the "kind" of users and security you need here is going to determine
>> what system you will choose for your web site. I mean, if you just
>> taking an existing Access form and converting it to the web, then likely
>> you want all your internal users + their existing "logon" to work for
>> this site (you would not want the wild internet to be able to use that
>> database).
>> So, the kind of users, the kind of security, the kind of logons - all
>> these questions have to be asked and analysed before you build any kind
>> of web site.
>> I am a big fan of FBA (Forms based authentication), and this means that
>> you don't have to use internal or what is called active directory users
>> from your company. This also means the issuing of external user logons
>> does not give these users permission to use your company network. And in
>> fact these FBA users are a SEPARATE group of users and logons. And as
>> noted FBA does open up the possibility of "self serve" or user created
>> logons without you have to create or invite such users. FBA is not a
>> option for office 365, but it is if you have your own SharePoint server.
>> However, as noted, we don't want to get into these areas of security and
>> authentication methods in this forum since the subject is far too
>> complex and far beyond that of being able to be answered in this post.
>> So I can no more explain the details and nuances of relational database
>> theory in this post, then that of attempting to explain the nuances and
>> choices you have in regards to security and authentication of users.
>> However, at the end of the day, unless you're hosting your own
"BobAlston" wrote in message news:5091E5AF.2050307@yahoo.com...
>So, with a E3 license can i set up an unlimited number (at least more than >50) different users
No, I never did mention E3 EVER in my post.
To be fair, when I originally looked at this, the number I recalled reading was 50 users (that my bad memory working here).
If you wanted to invite more, then you could purchase "bulk" users package.
These bulk external users ARE NOT 365 ACCOUNTS!!!!
So, we still talking about ONE p1 paid user account here.
However, the good (better) news is in fact as far as I can tell, the number is not and was not 50, but is 500 users.
>, for which I need not have them pay any license and they can use whatever >email address they like
Yes. The above is correct.
> as long as I properly address them?
Hum, now you 100% complete major huge and have utter lost me on this? I am not sure what you mean by "properly address them?"
To my simple knowledge here you can invite any user with any email to your site AS LONG as they associated that email with a live id.
(OR THEY are already using a legal live ID (Hotmail, live, or onmicrosfot)).
This LIVE ID setup and requirement does unfortunately mean THEY have to FIRST setup their email as a legal LIVE ID. The nice part is they can do this WITHOUT having to have any kind of live ID. So they can choose to associate any email with an existing live ID they have OR THEY CAN SIMPLY choose to create a live ID out of their existing email ID.
So they simply type in their existing email and choose a password for that email and they are done. This of course does use a CAPTCHA
(http://en.wikipedia.org/wiki/CAPTCHA).
And of course to setup this, they will then have a confirmation email to their inbox.
This setup process is reasonable quick and painless for these users (note how I said "reasonable")
On the flip side, this is somewhat of a hassle and pain for them since the user has to go through the process of setting this up one time.
To be fair, the bonus part of them "having" to do this means now it is THEM and THOSE PEOPLE that control and manage and change and take care of their logon ID and their password.
You thus don't have to ever administer these users in terms of lost passwords, having to re-set passwords etc. So the great part is you never have to deal with creating their logon's and you NEVER have to worry about setting their passwords etc. They are the ones that take care of this issue and they are free to change or re-set their password for their logon.
What this means all users will manage their logon and password on their own. In a very nice way the fact that THEY have to setup their email ID and setup a password to work with your site means you don't have to do this! So this does reduce and save you potential issues and much wasted time having to deal with forgotten passwords etc. like some systems force you to deal with.
As noted, I never mentioned E3, or having to upgrade the p1 account to a "higher" account..
Anyway, the number I see now is 500 users. To get another 500?
Oh, golly, I really don't know how that works. I suspect you likely have to purchase another p1 ID for an additional $6 per month. This would suggest that your p1 account now has two logons, and you would use the 2nd one to invite the next 500 users.
I would however ask about how to go beyond 500 users in some/one of the 365 support forms.
It would be an understatement to point out that asking about 365 licensing issues in an Access forum not going to work well! In fact I would bet you have a better chance of having questions about writing Oracle store procedures answered in this newsgroup then licensing 365 questions.
So licensing quite much way out of topic for this group and in fact quite much out of my area of expertise also!
However, I am kind of glad you asked, since I was quite sure the number is 50 and been stating that to many people (even in public). It now looks like I am wrong - it is 500 invites for one user - and this does not change regardless of what account you using (p1, E3 and so on).
-- Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
PleaseNoSpam_kal...@msn.com
>> So, with a E3 license can i set up an unlimited number (at least more
>> than 50) different users
> No, I never did mention E3 EVER in my post.
> To be fair, when I originally looked at this, the number I recalled
> reading was 50 users (that my bad memory working here).
> If you wanted to invite more, then you could purchase "bulk" users package.
> These bulk external users ARE NOT 365 ACCOUNTS!!!!
> So, we still talking about ONE p1 paid user account here.
> However, the good (better) news is in fact as far as I can tell, the
> number is not and was not 50, but is 500 users.
>> , for which I need not have them pay any license and they can use
>> whatever email address they like
> Yes. The above is correct.
>> as long as I properly address them?
> Hum, now you 100% complete major huge and have utter lost me on this? I
> am not sure what you mean by "properly address them?"
> To my simple knowledge here you can invite any user with any email to
> your site AS LONG as they associated that email with a live id.
> (OR THEY are already using a legal live ID (Hotmail, live, or
> onmicrosfot)).
> This LIVE ID setup and requirement does unfortunately mean THEY have to
> FIRST setup their email as a legal LIVE ID. The nice part is they can
> do this WITHOUT having to have any kind of live ID. So they can choose
> to associate any email with an existing live ID they have OR THEY CAN
> SIMPLY choose to create a live ID out of their existing email ID.
> So they simply type in their existing email and choose a password for
> that email and they are done. This of course does use a CAPTCHA
> (http://en.wikipedia.org/wiki/CAPTCHA).
> And of course to setup this, they will then have a confirmation email to
> their inbox.
> This setup process is reasonable quick and painless for these users
> (note how I said "reasonable")
> On the flip side, this is somewhat of a hassle and pain for them since
> the user has to go through the process of setting this up one time.
> To be fair, the bonus part of them "having" to do this means now it is
> THEM and THOSE PEOPLE that control and manage and change and take care
> of their logon ID and their password.
> You thus don't have to ever administer these users in terms of lost
> passwords, having to re-set passwords etc. So the great part is you
> never have to deal with creating their logon's and you NEVER have to
> worry about setting their passwords etc. They are the ones that take
> care of this issue and they are free to change or re-set their password
> for their logon.
> What this means all users will manage their logon and password on their
> own. In a very nice way the fact that THEY have to setup their email ID
> and setup a password to work with your site means you don't have to do
> this! So this does reduce and save you potential issues and much wasted
> time having to deal with forgotten passwords etc. like some systems
> force you to deal with.
> As noted, I never mentioned E3, or having to upgrade the p1 account to a
> "higher" account..
> Anyway, the number I see now is 500 users. To get another 500?
> Oh, golly, I really don't know how that works. I suspect you likely have
> to purchase another p1 ID for an additional $6 per month. This would
> suggest that your p1 account now has two logons, and you would use the
> 2nd one to invite the next 500 users.
> I would however ask about how to go beyond 500 users in some/one of the
> 365 support forms.
> It would be an understatement to point out that asking about 365
> licensing issues in an Access forum not going to work well! In fact I
> would bet you have a better chance of having questions about writing
> Oracle store procedures answered in this newsgroup then licensing 365
> questions.
> So licensing quite much way out of topic for this group and in fact
> quite much out of my area of expertise also!
> However, I am kind of glad you asked, since I was quite sure the number
> is 50 and been stating that to many people (even in public). It now
> looks like I am wrong - it is 500 invites for one user - and this does
> not change regardless of what account you using (p1, E3 and so on).
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
> PleaseNoSpam_kal...@msn.com
Hey, Albert. Just caught this thread. I love the idea that you can have up to 500 users per account, as long as the e-mail is associated with a Live ID, or is a Live ID e-mail account itself. However, I had trouble getting this to work.
On my Office 365-based account, if a non-logged-in user tries to do anything (e.g., select a value from a dropdown) which triggers a macro, they get an error message. Once they log in, it works fine. So that's as to be expected.
However, I created a Hotmail account for myself, added that e-mail address to my site, and gave that e-mail address full permissions to use the site. However, when I logged into my SharePoint site using the Hotmail account I had created, I got the same error messages that a non-logged-in user gets, even though I was logged into Hotmail, and I was logged into my SharePoint site using the Hotmail account.
I even tried bumping up the Hotmail account's user permissions to admin level, but it didn't affect anything. I simply could not get the site to recognize the Hotmail user account.
A person I work with on the site did the same - created a Hotmail account, and then I gave that account full permissions to the site. Same results. Kept getting error messages.
In both cases, the site showed the Hotmail account as being logged into the site. But it would function in the same way it does when a non-logged-in user uses the site - throwing an error whenever an action was performed. When we logged in using our Office 365 OnMicrosoft e-mails (both of which had been added to the site), the site worked perfectly. No problems. But it wouldn't work with the Hotmail logins. (I even waited a few days and tried again, thinking it might take time for the system to "recognize" the logins; but no luck.)
I did find, though, that you can use an Office 365 account from multiple login points. The client has like 3-4 people who might access the web site. So we are planning on having them have their own Office 365 account, and just use that single login between their 3-4 people who would access the site. Do you see any problems with this approach? Do you know of any limitations with using a single Office 365 login from multiple points simultaneously? (I, personally, was able to login simultaneously from 3 machines without any problem. All three logins remained active.)
~
On another, more philosophical note, I agree that people should have logins to modify data. However, it would be great if there could be a "Guest" account (with optional password) that could be used for people who just want to VIEW data. Would be great to be able to say, "If you want to look at the data, just go to the site, and log in using blah blah blah," and then they have access to view the data, but not edit it. That would be great, IMO, and, frankly, I don't know why they don't do that. They could still restrict the number of people logging in at once, so it wouldn't be open to the "whole world" at once.
