If you watch closely, you'll see my arms deftly handling the digital clapboard during the intro segment. By the way, The Birch is freaking AWESOME! John and Bryan had taken a break from doing their show for quite a while and are just now getting back into it. This is the second show since their return to the web. Enjoy!
Wednesday, 6 April 2011
I hope this isn't a bad omen?
The ConfigMgrSetup.log results from a recent site installation of SCCM 2007 R2.
When the last line says that everything is good to go, but the main word is mispelled, it doesn't make me feel warm and fuzzy.
Windows Web Admin (Final)
Final build (2011.04.06.001) is online and available for download at https://sites.google.com/site/skatterbrainz/downloads/wwa.zip?attredirects=0&d=1
The CAD Cloud. Finally. Citrix and AutoCAD 2012
Yesterday, Shaan Hurley dropped the long-awaited bombshell from Autodesk that 9 of their products are now certified for use with Citrix and XenApp. The internal cloud. IT admins the world over are sitting and staring into blankness as their brain cells rattle around like a ball in a spraypaint can, just trying to get their heads around what this means.
It means ONE INSTALL on a SHARED SERVER instance. Possibilities? Plenty: Client push installs? Gone. Client updates? Gone. Client upgrades? Gone. If you have a dozen or so clients this is probably not a big deal. If you have hundreds or thousands of clients - this is a huge deal.
System Requirements
Licensing and License File requirements for Citrix XenApp apps
AutoCAD performance recommendations for Citrix XenApp
Autodesk Press Release
Tuesday, 5 April 2011
Deploying AutoCAD with MDT 2010
In my latest book I discuss the various ways to automate the deployment of Autodesk products throughout a Windows network environment. Among these is "imaging". This is essentially where you automate the process of loading the base operating system, drivers, updates, and a set of "standard" applications on a new computer before delivering it to the user. If you're using a network-licensed version of an Autodesk product and the majority of your users use the product, then adding it to the base image might make sense in your environment.
Microsoft provides a free application called Microsoft Deployment Toolkit, or MDT, for creating custom imaging configurations for your various needs. This can range from various hardware models (drivers and utilities) to various user functions (role-based configurations for various departments or skillsets). It is also the required component for deploying imaging services within System Center Configuration Manager 2007, where it rolls up into what is known as the Operating System Deployment (OSD) feature. MDT employs a variety of components and toolkits such as WAIK (Windows Automated Installation Kit), .NET framework and so on. For more information about MDT visit the Microsoft TechNet MDT web site.
MDT uses a "task sequence" process that allows you to create a custom chain of events to install and configure everything you need on each computer. Think of it as being kind-of like a giant BAT script, but with a very robust GUI environment to work with. You configure which operating system, which service packs and updates, which drivers, which settings to customize, and which applications. You also configure the order in which these things are executed.
Why would you want to use MDT to deploy Autodesk Network-Licensed Products?
It can save on product network traffic overhead compared with pushing the installations out to computers in the environment. You can easily segment and isolate network traffic between the MDT host server and the workbench where the computers are imaged. This keeps the traffic off of your production routers and switches, thereby avoiding slowing down your users even during peak production hours.
Why would you NOT want to do this?
This is a bit tricky, and often subjective, but you have to consider how many licenses of the Autodesk product you have available (FLEXlm), compared with how often you max out usage, compared also with what percentage of your total computer user population could use a license at any given point in time. An example might be if you have 500 computers/users, but only 100 AutoCAD licenses. If 150 of your employees are potential AutoCAD users, especially frequent users, you may experience the dreaded "No available licenses / try again later" scenario. If you are in this scenario, then putting AutoCAD on every desktop and laptop might only exascerbate the problem by making it too easy for even casual users or curious folks (non-users) to attempt to launch AutoCAD.
The missing piece
Assuming you're not worried about the downside described above, and you wish to pursue adding this into your base image process, what do you need to do?
You need to create a Deployment share for AutoCAD. This is not to be confused with the "Deployment Share" referenced within MDT. That's a different deployment share. You have to create a network deployment share for the Autodesk product and create the deployment for the product to publish into that share. This is done from the installation media main setup interface. You will need to follow the same basic process as if you were creating a deployment for SCCM. You should make sure you include the installation of .NET Framework 4.0 before the task sequence item that installs the Autodesk 2012 edition of your products. You may also need to (separately) package the DirectX components. Last but not least, you need to make sure your command-line for installing AutoCAD includes the /I /Q and /W parameters (as shown in the NAG, or Network Administration Guide). If you forget the /W parameter, the installation will not pause the Task Sequence until it finishes, and will then create a problem where the next step begins execution before the AutoCAD installation is even partially completed.
If you build a proper AutoCAD Deployment and configure the Task Sequence within MDT properly, you should have a smooth process for including it in all of your newly imaged, or re-imaged computers before delivering them to the end-users.
Cheers!
Saturday, 2 April 2011
Estimation 101: Migrating an MS-Access DB to SQL Server
This is a very common scenario: A customer contacts me and asks "what would it take/cost for you to port our MS-Access database application to SQL Server and maybe put a web front end on it?"
That is quite often verbatim wording.
The answer I always give, and it's really not related to my being employed as a consultant, is "It depends."
Rather than dive into some ugly minutae, I'll give you the 50,000 foot skydive overview. This is the conceptual, philosophical level, not the technical or procedural level, but it's important for both business and technical folks to understand this at a basic level:
There are two basic parts to what most people call a "MS-Access Database Application":
1. The database content (i.e. the tables, queries, and data stuffed into them)
2. The interface (forms, reports, menus, toolbars, etc. which users interact with when using the application)
In general, when you migrate an Access Database Application to SQL Server you are really only moving the data and data structures (tables, queries, etc.), while the interface aspects require redevelopment with something to make either a client/desktop application (aka "client-server") or a web application. Examples include Visual Studio, ASP.NET or even ASP or PHP (note: there are many more possibilities, but I'm trying to keep this short)
If the database "application" provides no custom interfaces and simply has the user opening tables and queries to interact with, and use, the application - it's a piece of cake. You can either (A) use the Access "Upsizing" utility to "push" the data up to a SQL Server, or (B) use Integration Services to "pull" the data from the Access database into a SQL Server. I prefer [B] because [A] sucks and is too limited and inflexible while [B] is incredibly flexible and yields better results with less effort.
If the database "application" provides extensive interfaces like dynamic drop-down lists, graphics, radio buttons, checkboxes, toolbars or ribbons, well, it will take longer, but again: it depends.
Case 1: Migrating an Employee Database
The Access ACCDB (Access 2010) database contains a simple form for entering basic employee data to create a new employee record. There are a minimum number of tables and views and only one form. The database contains 20,000 employee records (rows). Only three employees should have rights to access the application and they are all in one AD security group.
One Solution: Copy the table structures and data into an existing SQL Server host and develop a web interface for managing employee records. The IIS web site is configured for Windows Authentication, the web app folder is secured with NTFS permissions for the AD group. The SQL connections are "trusted" with explicit AD group access configured in the SQL database. Total time to implement: 4 hours.
Case 2: Migrating an Asset Inventory Management Database
The Access MDB (Access 2003) database contains multiple forms, numerous tables and queries, as well as about a dozen reports. Some employees are allowed full permissions to edit records, while a select group is allowed only read permissions. Other employees are denied access. This results in 3 distinct roles. The roles are managed within the database (application security). The forms consist of many dynamic components and tons of clever graphics.
The company owns licenses for Office 2010 but has decided to hold off until this application can be updated to remove the reliance upon Access 2003. MDOP/App-V is not an option for this customer and neither is Embedded XP or Remote Desktop Services (TS Remote, Terminal Server, Citrix, Xen or whatever). They just want this beast killed and disposed of.
One Solution: Chain the Access developers to the back of a truck and drive off down a long gravel road at 60 mph.
There. That was easy now, wasn't it? Clear as mud.
Friday, 1 April 2011
Holy Cow! Strep and Couch Fatigue
I've been quiet lately because I've been getting punched out cold by a combination Strep infection + chest cough, so I've been spending more time on the couch watching Regis & Kelly, Rachel Ray and other daytime horrors that destroy the human mind. There's lots going on, but unfortunately I'm too worn out to type a lot just yet.
But on a really cool note, two of my books are in the top 10 of Amazon's Best Sellers in the "AutoCAD" category! Holy cow (times a hundred)! The latest book (AutoCAD Network Administrator's Bible, 2012 Edition) is at #7. The previous edition (2011 Edition) is at #9. I don't know what to say. I'm really surprised and I appreciate every copy purchased. See the list at http://www.amazon.com/gp/bestsellers/books/3483