If you work at a fairly junior level in the typical corporate IT environment your bosses will probably be treating you as a technician of categorised skills whose opinions and expertise outside of the narrow job box they have you in are neither of interest nor of value. Basically they tell you to do your job and keep out of everybody else's - and particularly theirs.
In my experience the less technically competent the IT management group is, the more harshly these role boundaries get enforced. Unfortunately, this behaviour is common, wasteful, and dishonest: the company has hired 100% of your applicable skills and directly or indirectly committed to helping you expand them, so restricting what you are allowed to do to the small percentage of your overall skill set that fits the niche they have you in both wastes most of what they're paying for and breaks their commitment to you.
There are a number of factors driving this, but the bottom line is that your opportunities for change in an established data center run by the Peter Principled are largely driven by organisational accident -you don't get a chance to show what you can do unless something unexpected happens and you're what the bosses throw into the breech.
But while you wait for lightening to strike, there you are: stuck getting a pay cheque for telling people to reboot, writing a daily network usage report nobody reads, repeatedly debugging the same people's relationship with the same piece of warehousing software - or repeating whatever other wonderfully unexciting bit of the daily grind they have you doing.
In that situation you face two related questions: should you try to break the cycle? and if so, how?
To me the rationale for doing what you want to - i.e breaking out of the safe but boring routine - is simple: it's pretty clear that the handwriting is on the wall for the present way of doing things and when something significant changes the people with the broadest range of skills will adapt first, and thus end up doing best.
Such change is inevitable - and the majority never gets it right in advance. All we know for sure is that the future will not be the past and therefore that just continuing what you're doing now is a long term loser.
So you need to expand your repertoire, but how?
The most effective strategies I've seen have all been social - the classic marrying the boss's daughter routine carried through at lower levels of commitment by working outside the organization to make yourself visible to your own user and upper management. Unfortunately that route usually requires having the right parents, going to school with the right people, or other social headstarts that simply aren't open to most people.
A less effective, but still workable, strategy is to make yourself over as a teacher of fringe technologies, like Linux, and let users create opportunities for you around those.
As a process this leverages management's assumptions about you - and their insistence on using only the technologies blessed by their strategic wisdom - to widen your role in the organization.
Step one in this is to find an HR or other company policy favouring training - and then sell your boss on sending you out for training subject to your promise that you'll conduct a few sessions in the office to pass on what you've learnt to your colleagues. Notice that the nature of the training doesn't matter - so pick something your boss cares about - because the point isn't what you learn, it's to establish the teaching precedent under which you pass on what you've learnt.
Once that precedent has been established, get yourself comfortable with at least one version of x86 Linux for the desktop and rely on the pass-it-on precedent to bypass opposition to doing an initial demonstration and seminar for your colleagues. Notice two things about this: first that you need to commit management to this process by getting their permission to use a bit of company equipment, space, and time for this, and secondly that you want to stress the home desktop, not servers because you don't want to scare your Wintel or zOS committed bosses and colleagues.
Now broaden the appeal to include the user community - do another seminar and make sure that somebody else invites a couple of user staff with some interest in home computing.
Pull that off, and you'll soon be home free: because this will make you the management blessed go to guy for user community PC hobbyists wanting to try Linux at home. And when that happens your bosses will be trapped between rocks and hard places the next time a user manager mentions some need for which there's no budget, but which could be met by loading Linux and some freeware on a disused x86 server - after all, everybody trusts you to make it work, and there's no cost, so how can he say "no" - aren't you his Linux guy?
Notice, however, that being seen prompting user management to do the requesting is the kiss of death for this strategy - your bosses will see that as an attempted end-run and find you a new job validating Microsoft licensing in an underground file room. Be patient: you'll be back to waiting for an organisational accident for a while, but appropriate issues come up all the time, and you can trust your bosses to eventually make just that one small exception to their uniform architecture rules needed to get some whiney user manager off their backs - especially if they see your failure as both inevitable and reflecting well on their normal strategy of sticking to more sincerely blessed technologies like Windows or the mainframe.
Of course, when opportunity finally strikes, you have to be ready to deliver: but here's a secret most Wintel/mainframe people refuse to acknowledge even to themselves: you know that rule about 90% of everything being bunk? well 90+% of getting a small project working in a large organization consists of organisational rules, and your bosses have just freed from those for this project - meaning that getting it working in the short term will be pretty easy - and getting it working in the longer term, well, isn't that the new job you wanted?