January 2006 - Posts
I've been a big supporter of
Nero Burning tools
for some time now. Back in the day I had all kinds of problems with the
tools that came bundled with my CD and noticed on the forums that I was
far from alone in this.
One day, someone suggested I try Nero, and I was hooked - here was the
powerful yet simple tool that allowed me to do everything I needed
without taking over my computer. Here was the tool that didn't take up
lots of resources when it wasn't running. Here was the tool that didn't
crash my computer constantly or order me to restart it 15 times during
install.
So I purchased a copy. And because I liked it, my college purchased a
copy... well 500 copies. And because I liked it, I pushed it at a lot
of people in the Microsoft newsgroups. I know quite a few people who at
least tried the demo because a
MVP told them to.
And I saw that all was good. Nero versions came and went as we needed
to update for new features and new drive support and all was good. Not
only did we like the program at work, but it was a nice lightweight
install that didn't add much to our build time and was easy to convert
to a MSI for easy network deployment.
Then came version 6. All of a sudden lots of other tools got thrown
into the bundle. Some of them were good and some of them were not so
good. I personally quite liked the showtime utility for watching
movies, and while I wasn't keen on Nero Express and other tools, I can
at least understand that others might use those parts.
However, all these extras and the changes to the main program made it
unsuitable for us to continue to use at the College, so I identified a
new (Freeware actually) program for use there, and again life was good.
Until today, when I upgraded to Nero 7. A 100Mb download just to burn a
few DVDs and CDs. Yes really. And then I ran the installer, which
needed to reboot twice before it actually figured I could use my system
again.
This wouldn't be so bad except that I was actually trying to do other
things besides install software at the time, that it left parts of the
old installation behind despite saying it would remove it and to add
insult to injury, allowed me to pick an install option that made it
impossible to follow their registration instructions, forcing me to
reboot once more(!) just to install an upgrade.
But it doesn't end there. I finally get around to opening the start
menu entry for it and what do I find? Or rather, what don't I find?
Well I don't find Nero Burning ROM! That's right, Nero has become so
full of bloat that the options for actually burning a disk have been
relegated to a tertiary level menu. But at least I can easily run "Nero
Home", apparently a pale imitation of
Media Centre or possibly
Front Row. And you thought the paperclip was a waste of space!
Now if only I wasn't already running Windows Media Centre on this
system, that might actually be helpful. I suppose it gives me something
to do while I try to figure out how to make a CD.
UPDATE (17 Jan 2006): The Sun have written back to me, apologising for
the mistake. See comments below for full text of the apology.
Dear Sirs,
I'd like to register my disgust at the shocking lack of bad taste your article here shows.
Quite aside from the slur on the character of several very good players
(Manninger and Boa-Morte both have league winners medals with Arsenal,
and several other players have enjoyed success based on what they
learnt while at Arsenal, so what exactly is your criteria here?) there
is the fact that you've had the very bad judgement to include Niccoló
Galli as a "miss" in your list.
Now I realise that facts and research aren't something you're very good
at so I'll try to help you refresh your memories. Here is the
Wikipedia
entry for Galli:
"Niccolò Galli (May 22, 1983—February 10, 2001) was a promising
footballer who tragically died in a road traffic accident aged 17. The
son of former Italian international goalkeeper Giovanni Galli, he began
with his hometown club, Fiorentina, before moving to Arsenal in August
1999. He spent one year in London, winning the FA Youth Cup in 2000,
returning to Italy with Bologna that summer. It was here that the young
central defender's career really started to take off, featuring in
Serie A and being recognised by Italy's youth teams, before his life
was tragically cut short.
The football training centre used by Bologna FC, in the neighbourhood of Casteldebole, is named after him."
His life, as it says above, was "tragically cut short" by a fatal road
traffic accident. Prior to this, he had enjoyed much success on loan at
Bologna and had been identified by both Liam Brady and Arsene Wenger as
an incredible talent who was definitely destined for the first team.
There is a
foundation named after him as well as the Bologna training centre.
I'd like to suggest that you owe the player's family an apology and
retraction of your baseless and tasteless claims. You managed to
disgust the vast majority of knowledgeable football fans with the trash
you printed about Hillsborough, and you've managed to do it again
today.
I will be posting this as an open letter on my website, and I look forward to your reply.
Regards
Rob Moir
This site is currently partway through migrating to the latest beta of community server, and also to new hosting.
Please excuse any oddities while this all gets sorted out.
[update]
All fixed and working now I think. Many thanks go to Genyus and
X.Static on the
Community Server forums for their help and patience
with me on this one, their help was invaluable in nailing the final two
known problems.
Yet again I'm going to repeat my endorsement of
Community Server as a
portal site for blogging, forums and the like. As you can see, it looks
real nice and is the best community portal that I know of - and
definately the best asp.net based one. And a first class support forum
is just the icing on the cake!
Short answer: "Yes with a but".
Long answer: Yes...
- But you'll need to create a partition on your virtual disk with
another OS installer or FDISK type program in order to create a
partition before installing Vista (Win 98 Virtual Floppy with FDISK
right here, ain't I good to you?)
- Virtual PC won't mount the ISO image directly, so burn it to a DVD.
- Allocate a lot of RAM. Really.
- Next, the install process will be V E R
Y S L O W
(imagine the spaces there meant I went and drank a cup of coffee
in-between typing each letter, to show you how slow it will be).
- Colin Barnhorst reports a 12 hr install in Virtual PC and poor
performance afterwards, with far better performance in Virtual Server.
- My virtual install took far less than Colin's install but still took far too long.
- Performance is slow in Virtual PC 2004 at the moment. I've also
tried it on a "real" computer and it isn't great there at the moment,
to be honest.
- Remember that this is very much a "work in progress" and should
by no means be taken as indicative of a finished product; whatever your
opinion is of Windows XP, I can assure you that the very first beta
build I saw of "Windows Whistler" was much much much worse than that!
More to follow, I'm sure. Oh, and before someone asks: NO I won't give you the Vista .iso nor my product keys. Sorry.
Re: Can Windows "Vista" install on Virtual PC? By tzuriel on 7/31/2005
as an FYI, instead of burning a DVD, which I didn't do
given that this is a pretty early beta and I would rather not lose an
entire 4.5 gb to a 2.7 iso, you can mount the iso with Daemon Tools and
install from there. Virtual PC thinks it's a regular hardware type CD
ROM and installation proceeded just fine. Sure took a long time though.
Thanks for the tip about the extensions. I wondered how I was gonna get
it to look better!
Re: Can Windows "Vista" install on Virtual PC? By Roberto on 7/31/2005
Thanks, thats a very good idea there that I missed - all
the more annoying when I actually have Alcohol 120% installed that
offers the same kind of virtual DVD drive!
[This post is one I managed to recover from the old blog system]
First of all... Yes you can install Exchange on a DC. If you somehow
found your way here from a google search while halfway through an
installation and need an answer right now, then your answer is "It
isn't ideal but yes you can".
If you were hoping for something a little more in-depth then read on…
First of all, the most obvious comment: this is indeed a Microsoft
supported scenario, and in fact something they do themselves if you
purchase the Small Business Server product and go with the defaults.
There are countless people out there right now using Exchange installed
on a Domain Controller who will never be aware of this discussion never
mind how many websites it has been covered on.
Small Business Server has a couple of important considerations however, that make it an 'edge case' for server setups.
- SBS is a compromise product. I don't mean that in any kind of
derogatory manner, but simply to say that the whole basic premise of
the product is that it is providing a broad range of services to a
limited amount of users.
- Exchange on SBS is essentially the standard edition of Exchange,
with all the limits that implies, which has an effect of rate-limiting
the amount of growth and resources it can do.
- Microsoft's deployment tools for SBS are written with all this in mind.
Installing Exchange onto a DC can be seen as a cost cutting exercise,
because it obviously reduces the amount of servers you need to buy.
Again, very true and correct. However, there are some considerations
that you should consider when totalling up the overall cost of this
choice.
Installing Exchange onto a DC introduces a number of problems, that are
not apparent on a server that is lightly loaded, but which can choke a
server that is heavily loaded; therefore a reasonable decision taken in
the early days of a network implementation can come back to bite you
later.
Both Exchange and Active Directory are based on resource hungry
databases, and are serving users in time critical functions. Both
systems can use large amounts of RAM; disk capacity and bandwidth; and
processor time. If these processes have to compete for those resources
then poor performance is your most likely outcome, and when it effects
the CEO's login times and email client behaviour, saving a bit of money
might not seem as important as it used to.
You can of course attempt to over-specify your server to take this into account. The problems with this are two-fold.
- I assume you hope your business will grow - so now you've got to
specify head room for growth in AD size, growth in Exchange size, AND
extra free room for them to share resources.
- The reasons for sharing a server we mentioned earlier were pretty
much based on the cost of buying two servers. Remind me again how
buying one big server for £8000 to share the two jobs is cheaper than
buying two £2,500 servers to keep the jobs seperated.
Another problem is security (you knew I'd get to that, right?)
If you want to use Exchange as a OWA or OMA web-mail server, then
you've not only got to expose an Exchange server to the Internet, but
now you've also got to expose a Domain Controller. Yes of course you
can firewall it all off, but this simple cheap solution is suddenly
getting less simple, and unless your time is worth nothing, that means
it isn't that cheap either.
Any outages that effect one service will have an impact on the other...
want to patch Exchange and need to reboot? Ooops, now nobody can
authenticate to anything because the DC is offline too. Want to patch
your DC? I hope nobody was working on an important and lengthy email
because they just lost it when you rebooted your DC.
Problems with applications that work with one service can affect the
stability of the other service. For example, a faulty Exchange virus
scanner would now also be in a position to upset basic network
operations.
Just to drive a final nail in the coffin - lets look at operational concerns.
Sharing a server means that more services are suddenly interacting with
each other. Now all of a sudden you've got servers that take forever to
reboot.
If you ever have to do a disaster recovery of your Domain controller
then guess what - your Exchange recovery skills better be up to scratch
too! Hate recovering Exchange servers after a disaster? Well guess what
- now you need to recovery a domain controller too - at the same time!
The issue here is not that the recovery is impossible, but rather the
cost of recovering one of these critical and sensitive services is
compounded by having to also recover the other one at the same time.
Any DC that runs Exchange needs to be a Global Catalogue server.
Exchange server functions that would normally fail over to using
different domain controllers if their preferred DC is not
available will not work as expected.
So obviously, I'm pretty much against the idea. In a small business
scenario with only one or two servers, it is acceptable if your choices
are either to do this or go without Exchange entirely, but as an
overall solution, it simply doesn't scale.
[This post is one I managed to recover from the old blog system]
I'm sure a few people have seen this happen: A small business starts
and decides it needs an Internet presence, and contracts with an ISP to
provide a basic connection to the Internet, some space for a webpage,
and a few accounts for employees held on the ISP's email system.
One
day, this business will hopefully expand to the point where it needs
more sophisticated messaging than this sort of setup offers, so what do
you do if this happens to you?
Firstly, what exactly are your
email/messaging needs? You need to consider several things when picking
where to go next, probably including some of the things on the list
below.
- Do you need to exchange a lot of internal mail?
- Do you want sales and customer services people to be able to record email exchanges with customers?
- Do
you have a statutory requirement to record communications with
customers or even a statutory requirement for controlling the storage
and disposal of these emails?
- Do your staff need to access emails both in the office and "on the road"?
- Do you need to integrate other things such as calendars and contact management into your work?
We're
using Exchange which offers all the above features very nicely (along
with several others). However, it only makes sense to go for a
sophisticated product like this or Lotus Notes if you intend to use
these "extended" features that such a product offers.
Mdaemon is
supposed to be very good too, I know a few places using this server
very happily. There is a large number of open source mail email server
type things out there that all work pretty good. Open Exchange
looks like fun if you've got the time to spend on it.
So we'll
assume you've chosen an email server product, and set it up on a
computer on your local network. Now you need to decide how email
reaches you from the outside world. You can have your ISP "Store and
Forward" email for you, or you can connect an email "gateway" to the
internet directly and let this talk to servers on the internet.
The
main advantage of the "store and forward" approach is that it works for
a company that doesn't want to have a permanent connection, and the
main advantage of the direct connection is simplicity.
In either
case, and in the interests of keeping this post to a managable length,
lets assume you can get the email from the internet onto your server.
Next you have to consider how your users will connect to their email on this server.
- Use
a POP3 client, transferring the emails off the server and onto the
client's account area. (I'm not a fan of this approach for any kind of
business to be honest)
- Use an IMAP system (or MAPI of course if you go for Exchange) that keeps email on the server.
- Use a webmail client
- (Robert's lock-on top tip solution for super happy email time)
Combine option "2" with option "3" for a flexible email system that
lets users manage their email with a full and powerful system when at
work, and still be able to check messages and do bits and pieces when
elsewhere.
POP clientsPOP3 clients are simple,
and are what most people who might already have used the Internet at
home or in a very small business will be used to. POP3 clients
typically pull email down from the server and store it on the user's
computer (or user's network drive or whatever), which makes managing
email retention, logging and disposal a nightmare, but is very simple
to set up and ensures you don't need to spend a lot of money on the
email server.
IMAP (and MAPI) clientsIMAP clients
leave email on the server and provide a view to the server to allow
users to work with their email. As the email is actually stored on the
server, it is easy to monitor and manage how emails are used and
stored. As such, this approach is one I would describe as mandatory for
a business with statutory requirements of any kind in this area.
Many
of the more sophisticated servers of this kind also allow you to save
space on message storage using a method that Microsoft refer to as
Single Instance Storage, but which I've also seen other products using.
Webmail clientsAs
you can imagine, webmail very much relies on leaving the email on the
server, and all the "server-side" advantages that I mentioned before
for the IMAP/MAPI approach also benefit here.
Webmail also has
the benefits of very easy client deployment and setup (every OS comes
with a web browser these days right?) and of allowing anyone with an
Internet connection to get their mail from anywhere in the world.
Webmail
suffers from underpowered clients. A web browser is not a good
application interface, and any webmail client will typically be less
capable, or at least slower and much more clumsy, than any "real" email
application.
IMAP and WebmailThe power and
advantages of a "real" email application in the office. The ease of
getting your email from anywhere in the world you can find the Internet
that webmail brings.
[This post is one I managed to recover from the old blog system]
A very good friend wrote to me recently asking for a few book
suggestions on networking and also on security to pass on to one of
their work colleagues, and I thought I'd make a note of my suggestions
here for whatever it is worth. Note that these are links to
Amazon.co.uk but not affiliate type links; you can buy with confidence
that I'm suggesting these books because I like them and not to line my
own pockets.
On a totally unrelated subject from security and
stuff, one book I’m pushing on everyone at the moment who might ever
have a need to present ANYTHING to clients or bosses or whatever is
Beyond Bulletpoints by Cliff Atkinson (website). You don't have to
suffer any more "death by powerpoint" moments... won't someone please
think of the children!
Anyway, books I’d always push on people about networking... I assume we’re talking about mostly above the physical layer.
- DNS & Bind
by Paul Albitz & Cricket Liu – a tough subject and not perhaps a
book to read cover to cover but you need this on your shelf as a
reference if you are serious about networking. There is a Windows
specific edition to this which isn’t a bad book if that is what you
need, but I suggest avoiding that and getting the more general guide
even if you expect to be working with DNS on Windows. DNS is a core
technology for any LAN or WAN network and needs to be understood as a
technology in its own right before you worry about different machine
implementations.
- Microsoft Encyclopedia of Networking
by Mitch Tulloch – no point in having the other books without being
able to look up odd phrases is there? I still use this to get the
“official” definition of things! If you don't like the Microsoft
Encylopedia then that is perfectly fine but you should have some kind
of encylopedia to hand.
- The Cabling Handbook
by John Vacca – The higher level networking stuff still needs something
physical to run on and this is a reference to the how and why of wire,
and more beyond that. This is a serious book for the physical design
side of networking.
- Ethernet: The Definitive Guide
by Charles Spurgeon – like the DNS book, not fun reading in and of
itself perhaps, but an essential reference and for all the same reasons.
As for security
- Maximum Security by
“Anonymous” (!) and published by SAMS – securing a network from the
hacker’s point of view. Some good stuff on practical attack vectors and
protections and on how hacker minds work.
- Hacking Exposed by Stuart McClure, Joel Scambray and George Kurtz – more of the same as above.
- Microsoft Encyclopedia of Security by Mitch Tulloch – [see justification of network encyclopedia!]
- Assessing Network Security
by Kevin Lam, David LeBlanc and Ben Smith – I think this is a very good
read for practical advice and guidelines on assessing risks on a
network and thinking about a course of action based on your assessment.
- Microsoft Windows Security Resource Kit
by Ben Smith, Brian Komar and the Microsoft Security Team - I might be
biased because my copy is an autographed gift copy from the first print
run, but this is a very good guide to locking down systems and networks
that involve Microsoft technology, which like it or not is most of them
these days.
- Incident Response
by Kenneth van Wyk and Richard Forno – People who know me know that
I’ve always said that people WILL get hit in the end no matter how good
they are... so this is a guide about how to respond when it’s you /
your organisation’s turn in the barrel.
Deployment scenarios - Complex Integration
- Builds on top of “Simple” integration.
- Implements Mac OS X server alongside the Windows Servers.
- Provides the best performance for clients working with large files.
- Enables simple OS X client deployment through NetBoot (Apple’s equivalent to RIS).
Complex integration is an extension of Simple integration by adding a
Mac OS X server to the mix to better manage the OS X clients, and
provides a chance to use a Mac Client/Server network and a Windows
Client/Server network side by side. This solution allows Mac and
Windows client computers to work with servers that natively understand
them when appropriate and only talk cross platform when needed, so this
gives lots of options for compromises when working with very large
files or with specialist client/server applications.
Another possible advantage is that Mac OS X server is a full featured
UNIX server system. As such, it can also be a good choice as a platform
for any UNIX based network software you wish to run (e.g. Apache, UNIX
mail servers, etc).
As you can probably guess, this is the most difficult configuration to
achieve, but the one that brings the most rewards. Also, you can
probably guess from the talk of Mac OS X server that this is the most
expensive solution to achieve in terms of new equipment required and
support burden.
This solution implements several Apple technologies to achieve its aims:
- Open Directory,
Apple’s equivalent of Active Directory, is implemented to mesh with AD
and manage user access to files on the Apple file server
- Open Directory also manages OS X workstations on the network, providing standard settings and configuration for things like login hooks (login scripts).
- NetBoot handles the deployment of OS images to new clients on the network, similar to Windows RIS technology.
- Apple’s AFP file sharing protocol talks to Apple network clients
natively, and the server also implements SAMBA file sharing for Windows
clients and servers. (Apple File Services)
Due to the complexity of this configuration it requires either a
moderate level of support on site plus consultancy for the
implementation phase of the project, or a high level of support on site
all the time. This can prove expensive.
As such, I only recommend this to places that are certain they can
justify a need at this level, it is rare that a site that is doing
nothing with Macs on their networks at the moment should suddenly need
to step up to this level of integration without taking a tour of at
least one of the other steps first!
Deployment scenarios - Simple integration
Macs become members of the Windows AD Domain, enabling user
authentication and management from active directory and relatively easy
access to facilities such as file and printer sharing. This is the
simplest step that can be considered “full” integration. Key to this is
the fact that Mac clients are now members of the Windows domain,
appearing in Active Directory.
Note that you CAN NOT apply GPOs or allocate MSIs to Macs!
Resources can be shared in both directions between the clients and
servers, but it is important to note that because of the fact that the
Windows networking protocols are not native to Macs, there may be some
performance issues when transferring very large files when compared to
native Windows to Windows or Mac to Mac file transfers.
Impact to budget is minimal
- No new equipment is needed for the integration over and above what you need to simply have the equipment in the first place.
- If you decide to standardise Mac client deployment then FireWire
drives may need to be purchased, but this is a minimal cost outlay
these days.
- Majority of costs are probably support related due to time spent
working with a new and possibly unfamiliar system, which brings me to…
Support staff need to be willing and able to handle the following:
- Desktop support of Macs
- The login process
- The creation of computer accounts for the Macs in Active Directory.
- Management of IP addresses for Mac systems, either via DHCP or by hand, plus DNS entries, etc.
This is where the “enthusiast user” or “support technician with one at
home” can fall down. As we all know, managing a computer on a network
is very different from playing Half Life 2 on one at home!
Some good news. Similar to Windows Terminal Services, Apple include a desktop viewing service known as
Apple Remote Desktop, which is compatible with
VNC. Microsoft also make a
Terminal Services client for OS X.
You can use these to allow administrators to manage both types of
platform from a single computer, or to make "Windows Only" applications
available to a Mac user without needing to keep two computers on their
desk.
Deployment scenarios - Minimal integration
- Occurs when the Windows network and your Mac Network share the same network wiring.
- Generally practical for sharing the same Internet connection and not much else.
- Poses little to no threat to either your budget or any support staff with Mac allergies!
- Depending on the rest of your network users may also be able to access facilities like corporate web mail and intranets.
In this scenario, the Mac computers typically exchange data between
each other using peer to peer networking techniques. They do not
usually exchange data with the Windows systems as this can be difficult
given that we’re not paying any attention to allowing easy
authentication to the Windows Servers at this point.
Hopefully just putting the Mac computers “On the Wire” at this point will enable them to access the Internet to run “
Software Update”
– the Mac equivalent to the infamous Windows Update – to pull down
system patches and suchlike to keep your systems and apps at the top of
their game.
While it might not sound like much, these benefits absolutely should
not be under-estimated; if you decide this is all you can do then you
have still made a very good start.
One important management benefit of this level of integration is that
it isn’t very intrusive or expensive. You need to nominate someone to
support putting the Macs onto the network, decide how you’ll handle IP
addressing and so-on, but it really should not interfere with your
Windows network in any way, nor should it greatly increase your support
burden. As such this is a good choice if you’re unsure and want to
“experiment” without risking too much, or if you worry about being able
to support more complex levels of integration.
Costs and Issues
There are several third party tools out there that aim to make
Mac/Windows integration easy. Microsoft in particular publish two tools
that can help with integrated networking;
Microsoft Services for Macintosh and
Microsoft Services for UNIX. These
are not required
and our integration was completed without any of these. Some sites may
of course have particular requirements that change the dynamic here of
course.
Networking OS X to Windows used to be a “magic” art, which drives the
legend that you must have these special tools, but has become much
simpler with the advent of Windows 2000 and 2003, and Mac OS X 10.3 and
10.4.
Let me settle the scary stories now:
- It isn't too difficult to get one Mac to log onto a Windows
network, and most of the scare stories about having to do scary things
like extend the AD schema simply are not true.
- There is no need to spend lots of money – unless you choose the “complex” integration method.
I don’t want to over-elaborate on this because it’s perfectly simple:
The cost of a minimal or simple integration of Mac clients onto a
Windows network is only very slightly higher than the cost of having
Macs at all, and most of the cost that does exist is realised in terms
of support technician time.
The case for integration.
Using Macs on a "standalone" basis increases the cost of managing them because the complexity of supporting them increases.
- It becomes difficult to deliver updates to them which can have an impact on reliability and security.
- Some packages may be especially sensitive to a need for updates, for example, virus scanners!
- How do you backup valuable work on a standalone?
The case against integration.
In order to use Macs effectively, there is a need for “Mac Aware”
users, though training requirements may be small. The user typically
drive the need for Macs on the network in the first place! If a user
knows that they want a Mac to perform their job effectively then they
will probably be knowledgeable on how to use it.
- On a standalone machine, a user can typically get away with just
knowing how to switch on and click the one item they want to use. A
network immediately increases the burden of learning required just to
use one simple program.
- Training requirements should be assessed in accordance with your normal procedures.
- The biggest issues will probably be with support staff far more than end users.
The “Mac vs. Windows vs. Linux”
holy war is an issue that
polarises any group of otherwise sane computer professionals in the blink of an eye, and many support staff will have an irrational fear of
any platform they don’t understand
Some time ago I was invited to give a talk on how to get Apple Macs
onto a Windows based network. While the talk never took place for one
reason or another, I had actually produced most of the material I
expected to be using for my talk and it seems a shame to waste it.
In this series of articles I will attempt to shine some light onto one
of the most commonly asked networking questions, with some practical
guidelines on what to do if you ever find yourself stuck with this kind
of project. I'll outline some of the risks and benefits of doing
this, and some common integration scenarios.
Assumptions
- When I’m talking about Macs, I’m talking about modern computers running OS X in general and OS X 10.4 “Tiger” in particular”.
- I’m assuming some basic knowledge of both Mac OS X and Windows on
the part of the reader– to go ahead with such a project both will be
required sooner or later.
- I am writing for the experienced Windows sysadmin with some Mac
knowledge rather than for the experienced Mac sysadmin with some
Windows knowledge.
- Where I talk about the monetary and support costs of integration,
I’m assuming that a need for Mac hardware and software has already been
identified, and as such, when I identify something as being
“inexpensive” I am speaking about the additional cost of taking that
step over and above having purchased equipment and software in the
first place!