Dec
9

Per-Proc Licensing… going the way of the Dodo ?

By Gerry V

A popular server licensing model is what licensing specialists refer to as “Per-Proc” or a model based on charging a separate Processor license for each processor that is located in the server. Additionally, under this model with a Microsoft Sever product, the customer is not required to purchase Client Access Licenses or “CAL’s,” and with a database server like Microsoft SQL, this is an attractive feature to many enterprises.

So everything is great, right ? Not so fast… 2007 has brought us the shiny new multicore desktops servers (yes, this author is writing this entry on a quad-core Intel chipset) bringing us greater multi-tasking performance, better graphics benchmarks and photo-realistic video games - however, its all one server or one desktop and one chipset so certainly we simply pay for one license, right?. The short answer is no. The software publishers see the multi-core as multiple licenses, so indeed the performance benefits come at a greater licensing price. Some customers have become very vocal about this seemingly inequitable structure - the “per-proc” model is so attractive to certain applications, especially web database applications that are pounded by end-users who may or may not have the appropriate CAL.

Ultimately this issue is still unresolved and the licensing specialists and Large Account Resellers are slugging it out. Don’t be surprised if we see some sweeping changes in the per-proc structure.

Filed Under Database, Developer, General, Servers & Infrastructure, Technology |

Oct
17

Using Windows Authentication with Reporting Services

By Mike G

This post will not explain how to set up using Windows NT Integrated Security to access data sources, I will only try to explain the difficulty of doing so and suggest an alternative.

Let’s say that you have a client machine, a report server and an MS SQL Server database that is on a different server than the report server. Using Windows NT Integrated Security means that the user’s credentials will be sent to the report server, and then the report server will pass those credentials on to the database server. Of course, this would require the sql server to give permissions to all of the domain users/groups that will be accessing the reports. The difficulty with this scenario is passing the credentials from the report server to the database server. The credentials that the user passed to the report server to begin with do not include the user’s password. The “credentials” consist of a Kerberos token. The report server can pass the token to a separate database server, but not by default.

Read more

Filed Under SQL Server 2000, SQL Server 2005 |