Discussion on:
View:
Show:
Typo at the start of step 5 where it says "There???s no need to go it alone in everything you so"
Take it all with a small Siberian salt mine. Ignore the above tips and do what works and makes sense for the organisation. While most of the tips are excellent, there are several real world issues with the tips presented:
1. Simplify. Absolutely. Get rid of legacy as soon as the new methods prove reliable.
2. Virtualize everything. Ummm... come again? How about a Linux embedded firewall in a SOHO setting? The point is that there is a point where a tool is and is not appropriate. Everything is a broad brush.
3. Review the service catalog. Good call. Why advertize that you will adjust the .ini files for a better WfW 3.11 experience in 2011? Again, getting rid of legacy is one of the most important and final parts of upgrading and standardization.
4. Project portfolio management. They will call it something else next week, but this has always been important. Today it's indispensable, particularly in software. The scope is different for small businesses as opposed to the IT department of a Fortune 500, but the theory is the same. To dance a polka, everyone has to be marching to the beat of the same accordion.
5. Consider the impact of outsourcing. When you save $20.00 per month, are you laying off three people to recoup the costs? What else do those people do for you? How much of a security risk is it? Are there any compliance issues?
6. Identity management needs to be done by the same team that does security assessments. If you allow HR to register new users, or worse, allow the users to self register, eventually you will end up with someone on the network who is not on the payroll... or at least not yours.
7. Self service. Good idea, but the implementation will make or break this. The software provisioning is a bit scary when you consider licensing, but I suppose it could be done. The rest is spot on. We should already be doing this.
8. BYOD. You bring it, you support it. We'll support the apps, but the device is yours, and thus your problem. We say it a bit nicer though.
9. When all you have is a hammer, everything looks like a nail. The cloud is a good idea for a lot of IT challenges, but is not the appropriate tool for everything. Walk into things with your eyes and options opened. Let the CEO spout the buzzwords and chase trends like his hair is on fire. Help the CIO make the right call.
10. Great advice. Wish I heard and groked this around Y2K. I learned this lesson then, at great personal cost. The war stories will cost ya a beer.
1. Simplify. Absolutely. Get rid of legacy as soon as the new methods prove reliable.
2. Virtualize everything. Ummm... come again? How about a Linux embedded firewall in a SOHO setting? The point is that there is a point where a tool is and is not appropriate. Everything is a broad brush.
3. Review the service catalog. Good call. Why advertize that you will adjust the .ini files for a better WfW 3.11 experience in 2011? Again, getting rid of legacy is one of the most important and final parts of upgrading and standardization.
4. Project portfolio management. They will call it something else next week, but this has always been important. Today it's indispensable, particularly in software. The scope is different for small businesses as opposed to the IT department of a Fortune 500, but the theory is the same. To dance a polka, everyone has to be marching to the beat of the same accordion.
5. Consider the impact of outsourcing. When you save $20.00 per month, are you laying off three people to recoup the costs? What else do those people do for you? How much of a security risk is it? Are there any compliance issues?
6. Identity management needs to be done by the same team that does security assessments. If you allow HR to register new users, or worse, allow the users to self register, eventually you will end up with someone on the network who is not on the payroll... or at least not yours.
7. Self service. Good idea, but the implementation will make or break this. The software provisioning is a bit scary when you consider licensing, but I suppose it could be done. The rest is spot on. We should already be doing this.
8. BYOD. You bring it, you support it. We'll support the apps, but the device is yours, and thus your problem. We say it a bit nicer though.
9. When all you have is a hammer, everything looks like a nail. The cloud is a good idea for a lot of IT challenges, but is not the appropriate tool for everything. Walk into things with your eyes and options opened. Let the CEO spout the buzzwords and chase trends like his hair is on fire. Help the CIO make the right call.
10. Great advice. Wish I heard and groked this around Y2K. I learned this lesson then, at great personal cost. The war stories will cost ya a beer.
Great comments, matter of fact better than the advice given. I do recall Y2K also although it was a piece of cake for me as I started to do the work for Y2K 6 months ahead of time. Never be surprise by anything has been my religion.
Virtualization works for a lot of loads but things that are going to affect everyones performance, like the firewall? Drop the extra few thousand and have a dedicated server for it. It will likely need to be an odd beast compared with your normal blade VM servers anyways since it will need all the FC cards in it for all the vlans, redundant internet connections etc.
6 is One of two points I'll take contention with. The first is software updates; group policy pushes updates if implemented correctly under AD. Don't use AD? Sucks to be you.
As for point 6, Identity management in a unified scenario is a brilliant, and oftentimes utopian pipedream that people will invest millions in. Reality is, unless you're willing to go single-vendor in terms of your IT software infrastructure, it's generally not going to work very well. (see: medical)
I'm personally a fan of having a single OS environment enterprise-wide, because you can solve all the same problems on linux, unix or windows, but the key is committing to one, and investing the capital in making your systems work for you.
As for point 6, Identity management in a unified scenario is a brilliant, and oftentimes utopian pipedream that people will invest millions in. Reality is, unless you're willing to go single-vendor in terms of your IT software infrastructure, it's generally not going to work very well. (see: medical)
I'm personally a fan of having a single OS environment enterprise-wide, because you can solve all the same problems on linux, unix or windows, but the key is committing to one, and investing the capital in making your systems work for you.
is vmware's marketing mantra, not a real world approach to computing. "Virtualize everything that makes sense to virtualize" is more appropriate guidance. Once virtualized, your domain controllers are now portable and can walk out of the data canter on a thumb drive. Is that the level of risk you really want? Every shop is different and virtualize everything is non sense for the vast majority of large orgs.
Obviously VMware has a vested interested in convincing everyone that the panacea to their problems is the magic button of virtualization. It's not very often virtualization really and truly makes sense, because the whole point of real virtualization is to allow different applications and services make use of hardware when loaded against other software on a different OS instance that has inverse load.
Generally speaking, hardware is cheap so there's no issue overloading whether your infrastructure is virtualized, or whether it's specifically purposed hardware. Virtualization ideally saves you time when you need to move an instance to new hardware, but generalization can do the same. In my experience (always loved that vaguery), the organizations who choose to virtualize just end up underallocating their boxes to the nth degree and in worst case scenarios implement NUMA node spanning so that their ram allocation bottlenecks and the unattentive admins never notice./ramblatribe
P.s. Virtualizing DCs? That's *very* close to jumping the shark, but valid. I know there's people dumb enough to do it.
Generally speaking, hardware is cheap so there's no issue overloading whether your infrastructure is virtualized, or whether it's specifically purposed hardware. Virtualization ideally saves you time when you need to move an instance to new hardware, but generalization can do the same. In my experience (always loved that vaguery), the organizations who choose to virtualize just end up underallocating their boxes to the nth degree and in worst case scenarios implement NUMA node spanning so that their ram allocation bottlenecks and the unattentive admins never notice./ramblatribe
P.s. Virtualizing DCs? That's *very* close to jumping the shark, but valid. I know there's people dumb enough to do it.
We have virtualised almost everything and will continue to do so. Hardware is not cheap when you consider it is under-utilised the majority of the time.
"It's not very often virtualization really and truly makes sense, because the whole point of real virtualization is to allow different applications and services make use of hardware when loaded against other software on a different OS instance that has inverse load." And therefore virtualisation makes perfect sense and works very well in the vast majority of cases.
"P.s. Virtualizing DCs? That's *very* close to jumping the shark, but valid. I know there's people dumb enough to do it." Why?
"It's not very often virtualization really and truly makes sense, because the whole point of real virtualization is to allow different applications and services make use of hardware when loaded against other software on a different OS instance that has inverse load." And therefore virtualisation makes perfect sense and works very well in the vast majority of cases.
"P.s. Virtualizing DCs? That's *very* close to jumping the shark, but valid. I know there's people dumb enough to do it." Why?
"Virtualize even you biggest Exchange, SQL, and SharePoint systems" If your large SQL server is using all its cpus and gobbling up as much memory as it can, then you aren't really going to gain anything by virtualizing it. In fact the overhead (albeit small) will make it perform worse. There also could be licensing issues since SQL will see virtualized cores as regular CPUs. Rather than making your life easier, it will give you additional things to worry about.
One of the big reasons to virtualize is to share otherwise wasted, idle hardware resources. If you have a very busy Exchange or SQL server, there won't be any wasted resources to share. You'll find the hypervisor will give it its own host to run on anyway, so what's the point?
One of the big reasons to virtualize is to share otherwise wasted, idle hardware resources. If you have a very busy Exchange or SQL server, there won't be any wasted resources to share. You'll find the hypervisor will give it its own host to run on anyway, so what's the point?
Exchange 2007 with 300 users, runs no problem with 10GB RAM and on a SAS LUN on the SAN. SQL Servers we also run on a dedicated LUN, again no problems. Our bigger SQL boxes we keep as physicals. You just need to be sensible with it, it's really not rocket science.
But the first thing that struck me is $$$,$$$,$$$.$$.
Weyerhauser tried this nearly two decades ago and, you know, it didn't work out.
Maybe now?
Maybe not.
If you have plenty of money and feel lucky, go for it.
Weyerhauser tried this nearly two decades ago and, you know, it didn't work out.
Maybe now?
Maybe not.
If you have plenty of money and feel lucky, go for it.
First thing I do is in a new org is build a Windows Deployment Services imaging server to push out a current OS (meaning not XP). When everyone has a clean easily deployed desktop OS, it is easier to focus on the long-term issues.
This is not a given, because imaging is a little more difficult in Win7 than WinXP.
Second is get yourself Windows 2008 domain controllers so you can manage the granular folder redirection available in Windows 7. Not just Documents, but Desktop, Bookmarks and links too. Assuming you have the space.
If someone loses their laptop, you have 99% of their most important work, much of which is stored on the desktop.
And no, virtualizing the desktop isn't ubiquitous just yet.
This is not a given, because imaging is a little more difficult in Win7 than WinXP.
Second is get yourself Windows 2008 domain controllers so you can manage the granular folder redirection available in Windows 7. Not just Documents, but Desktop, Bookmarks and links too. Assuming you have the space.
If someone loses their laptop, you have 99% of their most important work, much of which is stored on the desktop.
And no, virtualizing the desktop isn't ubiquitous just yet.
App-V. Take a look! Means that your base images, even the virtualized ones in your users hands, don't get molested by rampant installs, and you also get the added benefit of patching one install for the entire business. The only downside is extra terminal services licenses.
http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/app-v.aspx
http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/app-v.aspx
I find some of the advice here to be quite dangerous to the IT department. It actually sounds like a bunch of sales pitches strung together.
If the tool fixes the problem for a price your willing to pay you buy the tool. Personally I like the idea of virtualization. I worked at a large company that had tons of servers that were used by one department occasionally (a couple days a month). But they all run different OSs so they got dedicated boxes mainly because the department coughed up the dough for the software and server. But the needs could have been much more easily met by a few hefty servers that would be faster when loaded with their app and less idle because CPU time would be shared with others. Plus less network ports tied up, less cables etc. To me it wouldn't have been the cost it would have been how much cleaner the datacenter would be.
I was expecting something more along the lines of tips tasks that you could relegate to the Scheduled tasks app to be taken care of with minimal oversight.
I was expecting tips applicable at the tactical, day-to-day level, not at strategic levels above my own. This is good stuff for the managerial level and higher, though.
to handle this. Have you seen web sites with 'Did you forget your password' links? They work like that, with the user required to enter personal data initially.
So, not only will we have people sharing passwords, (being against the rules doesn't stop it,) we will also have people resetting each others' passwords. Can we get back to reality now?
This wouldn't exactly be self-service, but a manager could handle it for their team, rather than the IT dept.
5) outsource whatever possible and 7) do as much self service as possible are opposite mentalities and will not work together.
5) says to give as much as possible to contractors, but in 7) you are telling users to do it yourself. If the users have to do it themselves, why shouldn't the in-house IT dept. do it themselves? What is good for the goose is good for the gander!
And if the users are doing more themselves, who is going to help them, the contractors? (And they will need help! Don't kid yourself.) Are you going to have every individual user call the contractor for assistance? Yeah, those billable hours will be through the roof! You will be spending so much money, the next money saving tip will be in-house IT! And if the users have to wait for a contractor to help them, as opposed to the in house IT staff, lots of valuable time will also be lost.
It seems to me that these two tips are so opposite in spirit and in application, they shouldn't be in the same list. The more of one you have, the less of the other you can afford. Do you just want to do away with the IT dept?
5) says to give as much as possible to contractors, but in 7) you are telling users to do it yourself. If the users have to do it themselves, why shouldn't the in-house IT dept. do it themselves? What is good for the goose is good for the gander!
And if the users are doing more themselves, who is going to help them, the contractors? (And they will need help! Don't kid yourself.) Are you going to have every individual user call the contractor for assistance? Yeah, those billable hours will be through the roof! You will be spending so much money, the next money saving tip will be in-house IT! And if the users have to wait for a contractor to help them, as opposed to the in house IT staff, lots of valuable time will also be lost.
It seems to me that these two tips are so opposite in spirit and in application, they shouldn't be in the same list. The more of one you have, the less of the other you can afford. Do you just want to do away with the IT dept?
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
