I don't recommend any books on Sql Server; I don't think I've ever read one, and it wouldn't be ethical to recommend something I've never read. There are several reasons why I haven't read such books (not listed in order of importance, by any means):
1) I was reasonably fluent in SQL and relational algebra and relational theory a long time before SQL Server existed. I had had technical control of the design and implementation of a relational calculus based language (big research project) which was actually declarative (except for the transaction construct), had collaborated with Oracle and worked with Ingres and with Postgres, and had worked with a consortium of European companies on proposals for enhancements to SQL, before my first contact with SQL Server.
2) The concepts and good practises of administration (ensuring reliability, security, recoverability, adequate performance) are mostly independent of the particular dbms system, so I didn't see any reason to read a book as opposed to consulting the excellent reference material provided as BoL (and other bits of the MSDN library).
3) I prefer reading the sort of material I used to find in research reports from various companies and universities, in Sigmod conference proceedings (and VLDB, and others) and in journals like ACM ToDS to reading the sort of rubbish that finds its way into most text books, whether vendor/platform spacific or generic.
4) Text books were/are a silly price, unless one steals them (which would be against my principles). This is I think caused by (a) very low sales volumes (compared with pulp fiction, fo example) and (b) very rapacious publishers ((b) is also a significant cause of high piracy levels and lousey author remuneration).
5) I found that SQL Server, apart from bizarre idiocy here and there (much of that inherited from the SQL standard, which is in some ways an appalling mess) was quite sane and rational in its design and user interfaces, it was easy to build a mental model of what it did and how it did it that would enable one to get by without too much time checking the reference material.
6) When caught by the absence of information in MSDN (frighteningly frequent) I found that there was plenty of information on the web, some of it was actually correct, and the incorrect stuff was usually easy to spot (usually, not always - which is, unfortunately, inevitable; actually the general standard is about the same as the general standard for textbooks).
7) I had found other database textbooks painful; some were offensively inaccurate; some were putting more effort into grinding axes (conveying author prejudices) than conveying useful information; some had clearly suffered no proof reading, or perhaps proof reading by people who neither knew the subject nor spoke English (this was an amazing contrast to maths textbooks, which tended to be far better proofed); some were grinding commercial axes (designed to boost one DBMS product and malign others); and most appeared to be aimed at cramming low-value short-life transient information about the vagaries of a particular releas of a particular product, rather than explaining the ideas behind the product and how to use it to best effect. So I expected SQL Server text books to be the same, and never read any.
I think reasons 2,4,5,6, and 7 probably apply to most people (1 or something analagous applies to a lucky few, of which I am fortunate to be one; and 3 is purely a matter of personal taste). And for me, these reasons have over-ridden my preference for a real paper book that I can read curled up in an armchair or streched out on the grass or on a bed or in a bath (even though I still buy real paper books on maths, and physics, and languages, and dictionaries, and music, and pretty much everything else: just not database textbooks) when something strike my fancy.