(Note: This is going to be an ongoing series, I think. It depends on feedback from folks like you)
Question 1 - "In VMware Workstation and VMware Player, it has an option to preallocate the virtual hard drives. What does this do and why should I consider it?"
Answer: It carves out physical storage space (on whatever drive/disk/volume you have it pointed at) to store the disk .VMDK file before using it the first time. Like most things in life, there's a trade-off...
On the good side, preallocating space avoids the need to incrementally allocate more space as needed. The incremental growth usually happens while the VM guest is running, causing some delays and pauses at times.
On the bad side, preallocating space takes up designated storage space which may not be fully-used on the inside (guest VM referencing). For example, if you specify a 60 GB disk, it will grab 60 (plus a little chump-change space for overhead) right away. In the end, you may only end up filling 40 GB within the guest machine, leaving 20 (or thereabouts) unused but still occupied on the physical disk.
If space isn't a concern, preallocate it to squeeze a little more performance from your virtual toyland.
Question 2 - "If I want to roll out a new Group Policy ADMX template during production hours, what negative impact would that have?"
Answer: "Would" or "Could"? The answer depends on several factors. But starting at step 1: deploying an ADMX template into an AD environment involves updating the SYSVOL on the first domain controller. From there it replicates (because domain controllers like to replicate, as nasty as that sounds).
The factors that come into play after step 1 are like a Rubik's cube. Site link configurations, replication schedules, the size of the ADMX files, the WAN links, the network configuration, the KCC mess in the background, the amount of drugs your engineers consume, the prevailing winds, the high tide, the... whatever. Hopefully you get the idea. I would recommend that (after you've tested them in a separate environment of course) that you deploy them during off-peak hours. If that isn't possible, blame it on the last person to have quit.
Question 3 - "Will shifting my SCCM environment over to a user-demand, Application Catalog scheme fix all my problems with overseeing software deployments?"
Answer: It depends. In general, the answer is "no", it won't fix "all" of those "problems". Can it lessen your workload? At best: usually. At worst: it will replace one set of problems with another.
Will it eliminate some problems on the whole? Sometimes.
It depends on how diverse your applications are and how diverse the target platforms are in your SCCM site. If you support 4,000 products, but they are well-defined in terms of assigning one product+version for each business role, then you will be better off. If you have a lot of alternatives for the same role/purpose, start drinking and get your Liver in good shape.
The surprise "gotchas" I've seen, or heard about, with handing over the role of installing applications to end users via a catalog shopping-cart concept, have been basically from two general areas. Each of which breaks down into two more areas:
1. Setting up the catalog
2. Cleaning up messes
The first area (setting up the catalog), involves not only building the catalog, but assigning roles and permissions, but that's the easy part. Then comes the spaghetti-like enigma of validating product licensing and usage terms, as well as planning out the potential conflicts. Those are the nasty things like "Product A and Product B cannot exist on the same client or they break things." or "Product A only works with .NET 4.0 while Product B only works with .NET 4.5" and so on.
The second area (cleaning up messes) involves hand-holding users that mistakenly install things and run into problems with them. Even if you teach them how to remove those mistakes, there are going to be the breaks that require rolling up your sleeves and taking time away from other work.
The secondary issues are delegation reliability, and platform resiliency. Big words. I like big words.
The former (delegation) involves how well your delegated staff hold up with handling rights and assignments, as well as tech support issues that arise. The latter (resiliency) involves how mature your environment is with regards to platform standards and methods for repairing breaks in the assembly line. How many versions of Windows you support, how many device types, models, vendors, component versions (JRE, .NET). Good stuff for beer talk.
Question 4 - "Is it more important to have a college degree or a certification when entering the IT field?"
Answer: My kids' friends and their friends hit me with this question a lot. Usually after some introductory phrase like "Excuse me, old man? Can I axe yuze a question about getting a computer job?".
From an entry perspective (first-time job seeker), it depends on what kind of IT job you're aiming for. If you're looking for a fairly low to intermediate job, such as anything from Tier1/desktop support, to even Systems Admin or Systems Engineer, it helps to have a degree, but it really helps to have a lot of (current/recent/relevant) certifications.
Many entry level IT jobs only require A+, Network+ and Security+ certifications, unless you start getting into VMware or Cisco type stuff (and so on). Even then, having a Microsoft MCSA/MCSE will help a lot.
If the job your aiming for is "senior research scientist" or "database architect", well, start filling out those college enrollment applications. It won't hurt to have your CCNA or MCSE/MCwhatever, but most high-level, expert type fields within IT expect more educational background. And don't forget those Analysts and Project Managers, who may need a mix of schooling and certs like PMP, ITIL, etc. Just poke around the job postings online and you'll see what I mean. (Not that I've been looking of course, cough-cough. That's just what I've been told).
Question 5 - "What is the toughest part of getting technology to work well?"
Answer: People. It's just human nature to try to pound nails using a wrench.
(Thank you for reading! Stay tuned for more IT stupidity coming soon...)
No comments:
Post a Comment