Dwarfsoft [GPA]

Changing Roles

by on Jun.30, 2008, under Novell, Politics, Scripting, Work

Print This Post Print This Post

Interesting moves happening at work. Today I moved into a Networks role. Originally it was intended that I be doing 80% Servers and 20% Networks due to the solid input I have provided within the Server team to date. This has now been changed to 80% Networks and 20% Servers. The guy who I am filling in for didn’t like the idea of his role being technically abandonned, and I agree with him. There will definitely be some Server Action from my end anyway, because I have a keen interest in running with a few ideas.

Trav and I have approached the Server team with an idea on distributing apps more effectively, relying mainly on network addresses of the PCs to correctly locate an application server. This brings up a few logistical hurdles.

  1. The restructuring of our Applications such that we can point to a mapped network drive instead of relying on UNC paths.
  2. The fact that some applications are released with site specific information. As we currently have to modify every new release of these apps to include that information, we should approach the issue from a more managable perspective.
  3. The Implementation of Login Scripts to Base Drive Mapping on current Network Location instead of the Current Login or Workstation Context or Group (as this then provides a benefit of decreased WAN traffic for Mobile Computers and Distributed Applications).
  4. The Politics of testing and gaining approval for implementing a new process into something that is seen as a working system. This is possibly the greatest hurdle to overcome in regards to the push for initiative.

At least with respect to point Number 4, Trav and I raised this with one of our counterparts in the Server Team, and although we were given some good reasons why some of the ideas we initially had could not go any further than the drawing board, he did provide some additional ideas on how to proceed to at least implement some positive change so that we can all manage our site specific apps (Point number 2) more effectively.

The thing we need to concentrate on first is going to be appropriating some hardware and then building an environment in which we can test some of our theories that are not being implemented. In the mean time I will start testing some of the ideas that the team has approved at this point.

Hopefully we can implement a ZfS Server that creates NALs under the District Container (as opposed to our site containers) which uses %DEST-APPS1% as X:\ instead of a UNC path, and use a Cluster Wide Login Script to appropriately map X:\.

One parting thought on another issue this could have on us, that the X:\ drive is not consistent around the state. From ZfS’s perspective, everything is all well, however there are a lot more things stored on the X:\ drive that are used constantly from a Technical perspective. This will possibly require some more training, or at least another drive mapping…

Until I start looking into DFS at least 😉

In three weeks time we shall see what position I am in though, before too many things are set in stone.

Cheers, Chris.

:, , , , , , , , , , , , ,

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!