From: Tony Toews [MVP] on 23 Sep 2009 00:56 Folks For putting some restrictions on licensing a utility to businesses I'd like to include the server name in the license key so if it changes they need to contact me. Do the various API calls at vbnet.mvps.org such as the following work on Linux or Novell Netware servers? Hmm, Novell seems to exist but it looks like maybe Netware is extinct. NetGetJoinInformation: Join Information for a Local or Remote Machine <http://vbnet.mvps.org/code/network/netgetjoininformation.htm> NetServerEnum: Get Version Info for Domain/Workgroup Servers and Machines <http://vbnet.mvps.org/code/network/netserverenumver.htm> NetServerEnum: Obtain Domain/Workgroup Servers and Machines <http://vbnet.mvps.org/code/network/netserverenum.htm> That said I suspect I won't get many such as this utility is for Access. I'm also just started adding some functionality for which I'd like to get paid as this utility has been a few download since about 2001. www.autofeupdater.com if any one is interested. The next question though is such a restriction even necessary? My utility is being used in many organizations around the world including Fortune 10 companies. So if it's run in ten different departments on ten different servers then I see no reason why I should sell them one license key with just their overall business name in it. I'd like some money at least for all ten servers. Hmm, ,maybe I should have a two line business name for the business group and location and such to narrow down where the license is for. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
From: Richard Mueller [MVP] on 23 Sep 2009 12:03 "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message news:r4ajb5ppdu240775e3lel6pl56al0ufov1(a)4ax.com... > Folks > > For putting some restrictions on licensing a utility to businesses I'd > like to include the server name in the license key so if it changes > they need to contact me. > > Do the various API calls at vbnet.mvps.org such as the following work > on Linux or Novell Netware servers? Hmm, Novell seems to exist but > it looks like maybe Netware is extinct. > > NetGetJoinInformation: Join Information for a Local or Remote Machine > <http://vbnet.mvps.org/code/network/netgetjoininformation.htm> > > > NetServerEnum: Get Version Info for Domain/Workgroup Servers and > Machines > <http://vbnet.mvps.org/code/network/netserverenumver.htm> > > NetServerEnum: Obtain Domain/Workgroup Servers and Machines > <http://vbnet.mvps.org/code/network/netserverenum.htm> > > That said I suspect I won't get many such as this utility is for > Access. I'm also just started adding some functionality for which I'd > like to get paid as this utility has been a few download since about > 2001. www.autofeupdater.com if any one is interested. > > The next question though is such a restriction even necessary? My > utility is being used in many organizations around the world including > Fortune 10 companies. So if it's run in ten different departments on > ten different servers then I see no reason why I should sell them one > license key with just their overall business name in it. I'd like > some money at least for all ten servers. > > Hmm, ,maybe I should have a two line business name for the business > group and location and such to narrow down where the license is for. > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > Granite Fleet Manager http://www.granitefleet.com/ I believe the api's are implemented in netapi32.dll, which I suspect is only in Microsoft Windows OS's. However, the RootDSE object is an industry standard for all LDAP compliant servers. Among the properties of this object are defaultNamingContext, serverName, dsServiceName, and dnsHostName. See this link: http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx Of course, any method to retrieve a server name will most likely retrieve the name of the server the client machine authenticated to when it started. This could be a different server each time. Would the DNS name of the domain (the defaultNamingContext property of the RootDSE object) work better? If your utility only runs on servers, then you want the name of the local computer. If the utility runs on any client, any call for the name of a server could return any one of many names, unless there is just one DC in the local site. -- Richard Mueller MVP Directory Services Hilltop Lab - http://www.rlmueller.net --
From: Richard Mueller [MVP] on 23 Sep 2009 16:52 "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in message news:u4q63dGPKHA.5108(a)TK2MSFTNGP02.phx.gbl... > > "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message > news:r4ajb5ppdu240775e3lel6pl56al0ufov1(a)4ax.com... >> Folks >> >> For putting some restrictions on licensing a utility to businesses I'd >> like to include the server name in the license key so if it changes >> they need to contact me. >> >> Do the various API calls at vbnet.mvps.org such as the following work >> on Linux or Novell Netware servers? Hmm, Novell seems to exist but >> it looks like maybe Netware is extinct. >> >> NetGetJoinInformation: Join Information for a Local or Remote Machine >> <http://vbnet.mvps.org/code/network/netgetjoininformation.htm> >> >> >> NetServerEnum: Get Version Info for Domain/Workgroup Servers and >> Machines >> <http://vbnet.mvps.org/code/network/netserverenumver.htm> >> >> NetServerEnum: Obtain Domain/Workgroup Servers and Machines >> <http://vbnet.mvps.org/code/network/netserverenum.htm> >> >> That said I suspect I won't get many such as this utility is for >> Access. I'm also just started adding some functionality for which I'd >> like to get paid as this utility has been a few download since about >> 2001. www.autofeupdater.com if any one is interested. >> >> The next question though is such a restriction even necessary? My >> utility is being used in many organizations around the world including >> Fortune 10 companies. So if it's run in ten different departments on >> ten different servers then I see no reason why I should sell them one >> license key with just their overall business name in it. I'd like >> some money at least for all ten servers. >> >> Hmm, ,maybe I should have a two line business name for the business >> group and location and such to narrow down where the license is for. >> >> Tony >> -- >> Tony Toews, Microsoft Access MVP >> Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm >> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ >> Granite Fleet Manager http://www.granitefleet.com/ > > I believe the api's are implemented in netapi32.dll, which I suspect is > only in Microsoft Windows OS's. However, the RootDSE object is an industry > standard for all LDAP compliant servers. Among the properties of this > object are defaultNamingContext, serverName, dsServiceName, and > dnsHostName. See this link: > > http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx > > Of course, any method to retrieve a server name will most likely retrieve > the name of the server the client machine authenticated to when it > started. This could be a different server each time. Would the DNS name of > the domain (the defaultNamingContext property of the RootDSE object) work > better? If your utility only runs on servers, then you want the name of > the local computer. If the utility runs on any client, any call for the > name of a server could return any one of many names, unless there is just > one DC in the local site. > > -- > Richard Mueller > MVP Directory Services > Hilltop Lab - http://www.rlmueller.net > -- > You may need to describe your architecture. Thinking more about your question, I wonder if by "server" you mean the computer where your Access database resides. It may be a Domain Controller, a member server, or an XP workstation. Perhaps you want to enforce one database per license, but not restrict the number of clients that can run your application and access the database. With an SQL Server database one approach is to publish the application in Active Directory. SQL Server has one stored procedure to publish the SQL Server instance and another to publish a database. This creates objects in the computer object (the computer object acts as a container). This makes it easy for an application to query Active Directory for objects of the correct class with the name of your application and retrieve the name of the computer so you can construct a connection string to connect to the database. If the application finds more than one, it knows the database has been installed on more than one computer. Something similar could be done for an Access database, but of course this would only apply to customers with Active Directory. The only other way I can see for the client application to find the server (assuming client server setup) is to store the name of the server (the computer with the database) in the local registry, perhaps during setup. Otherwise the application must assume that the database is on the same computer, in which case it is easy to retrieve the name of the local computer. -- Richard Mueller MVP Directory Services Hilltop Lab - http://www.rlmueller.net --
From: Tony Toews [MVP] on 23 Sep 2009 20:48 "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote: >You may need to describe your architecture. Well, that's just it. My VB6 utility runs on all kinds of servers although mostly Windows servers. So I don't know what server architecture my utility runs on. >Thinking more about your >question, I wonder if by "server" you mean the computer where your Access >database resides. It may be a Domain Controller, a member server, or an XP >workstation. Correct, that's more what I was thinking. I was thinking of putting in a license check for the Active Directory domain name (or something similar) and the Server name on which the utility resides. But then I got to thinking about Novell and Unix networks. Now there won't be too many of those running Access apps (which is what my utility assists with) but there will be some. >Perhaps you want to enforce one database per license, but not >restrict the number of clients that can run your application and access the >database. Well, I'm happy with my utility being used on many Access databases. It's the servers I'm more interested in. >With an SQL Server database one approach is to publish the application in >Active Directory. SQL Server has one stored procedure to publish the SQL >Server instance and another to publish a database. This creates objects in >the computer object (the computer object acts as a container). This makes it >easy for an application to query Active Directory for objects of the correct >class with the name of your application and retrieve the name of the >computer so you can construct a connection string to connect to the >database. If the application finds more than one, it knows the database has >been installed on more than one computer. Something similar could be done >for an Access database, but of course this would only apply to customers >with Active Directory. Ahh, interesting. Thanks for that idea. >The only other way I can see for the client application to find the server >(assuming client server setup) is to store the name of the server (the >computer with the database) in the local registry, perhaps during setup. >Otherwise the application must assume that the database is on the same >computer, in which case it is easy to retrieve the name of the local >computer. Well, the user has to store some settings in an INI file on the server from which my utility runs. So even if the share is a drive letter I can still get the UNC name of the server and share. So at least I'd get that server name. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews [MVP] on 23 Sep 2009 20:54 "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote: >I believe the api's are implemented in netapi32.dll, which I suspect is only >in Microsoft Windows OS's. However, the RootDSE object is an industry >standard for all LDAP compliant servers. Among the properties of this object >are defaultNamingContext, serverName, dsServiceName, and dnsHostName. See >this link: > >http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx Ahh, that helps. I do have one client to which I login on a regular basis running a complete Win 2008 Server with Active Directory and so forth. One thing I've noticed is that to hit his network I have to enter a domain name on the VPN which he has setup as "xx.local". where xx are the initials of his employers business name. Now knowing him he's done things the right way and I should consider using that field as one of my licensing limiters. >Of course, any method to retrieve a server name will most likely retrieve >the name of the server the client machine authenticated to when it started. >This could be a different server each time. Would the DNS name of the domain >(the defaultNamingContext property of the RootDSE object) work better? If >your utility only runs on servers, then you want the name of the local >computer. If the utility runs on any client, any call for the name of a >server could return any one of many names, unless there is just one DC in >the local site. I'll copy a portion of my reply to your other posting. Well, the user has to store some settings in an INI file on the server from which my utility runs. So even if the share is a drive letter I can still get the UNC name of the server and share. So at least I'd get that server name. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
|
Pages: 1 Prev: anyone use iGrid form 10tec Next: ActiveX DLL (for Olaf) |