Trials and tribulations of a new Admin.

[nutcase]

We have hundreds of the same files saved in different places - 300+ sometimes.

It's a business policy to do this but it's now been agreed to use a shortcut instead. Is there an easy way for me to replace these files with a shortcut to a central copy of it?

Yes I know dedupe would help, but it's on a 2008 server and will be for the time being

thanks

 

[skyripper]

These files all have the same name, size and date?

Write a script to identify duplicates and make a link to the master copy.
There are utils to create shortcuts from the command-line, or you could create one manually and copy the .lnk file around

Or if your users/applications can't cope with Shortcuts, look at Hard/Softlinks (mklink.exe I think) for an OS level alternative.



Think of the space saved. Just make sure the master copy is Read Only for everyone! Or one persons change will **** up everyone else.

 

[nutcase]

Just changing two of the files for shortcuts will save 6GB...

I'm no script kiddy I've found something that replaces a files with an identical file (the intention being to update to latest version) but can't find anything to swap one file for another

 

[GDL]

Add one copy to a DFS path with user permissions to read only.

Move the other copies to a location that the users don't have access to.
Delete after a few weeks.

 

[nutcase]

Still not figured out how to swap the files

Got another one though - there's a printer attached to one server that I need to change the permissions on - except the owner is system (which appears to be normal) but administrator has no permission apart from take ownership.

How can I get administrator more permissions? Thanks

 

[Quartz]

Just Take Ownership. But before you do, determine what the permissions should be, so you can apply them afterwards.

 

[nutcase]

That's all I can do though - take ownership. I still can't change permissions...

 

[ChrisD.]

If you're the NTFS owner then you can do what you like with it?

 

[Quartz]

That's all I can do though - take ownership. I still can't change permissions...

Once you Take Ownership, you will be able to set permissions.

 

[nutcase]

I can't - it's still greyed out.

 

[nutcase]

This is what I see when I've taken ownership:

 

[nutcase]

next issue I'm seeing, I think I know the answers to - but would like a sanity check before I go cap in hand to the powers that be...

VM host - 3Gb teamed NIC
Veeam repository - 2Gb teamed NIC

I'm seeing massive dropped transmit packets during the backup window. First thing I'll try is knocking the host back to a 2Gb NIC so it's not trying to squeeze 3Gb down a 2Gb pipe...

But I'm seeing dropped transmit packets the other direction as well - over 10 million when I ran a restore test.

One think I've learned is that Netgear don't advertise the Mpps rate. We have a couple of HP 1920s that advertise a 14.8 Mpps so no sure why Netgear don't advertise? The netgear has a 2MB buffer but I'm not sure that's overly relevant because if it can't pass the packets quickly enough, it will just fill up and start dropping - it's the Mpps rate that is more important?

I'm thinking we need a better server cupboard switch to cope with the backup traffic?

 

[ov_sjo]

You don't need to put the host back to 2 GbE. That won't make any difference.

Also i've not come across a switch which can't handle line speed on every port, so don't worry about that either.

Are the devices hooked up directly to the switch or via structured cabling? Dropped packets are usually either cabling related or obscure incompatibilities with auto-negotiation mode between different brands. Try new patch leads and hard setting the interfaces rather than auto (if not already).

 

[nutcase]

Both devices are (at present) directly connected to the same switch by patch leads. The repository is connected with new leads (no guarantee of course) and the host is re-using ones from a previous server but still only a couple of years old. Think I've seen a basic lead tester somewhere I could try.

I'll also set the ports to fixed gigabit instead of auto though. edit: except it would seem the only settings are auto, 10 and 100 so can't fix them at gigabit.

Thanks

 

[ov_sjo]

It's not just the ports on the switch, it's the NICs in the devices too.

Check for hard errors on the switch ports.

 

[nutcase]

I've upped the monitoring on the switch and servers. I've got to nip into the office tomorrow so will try different patch leads.

 

[Deleted member 138126]

A few things:

- TCP has flow control, so there's no such thing as "jamming 3Gb down a 2Gb pipe"
- Dropped packets only occur through mis-configuration or faulty hardware
- You rule out hardware by removing all teaming and just using a single NIC on both servers (remove all teaming configuration not only from the servers but also from the switch ports)
- It's surprisingly easy to get mis-configured teaming. There are quite a few dependencies between the operating system of the server and the brand/model of the switches

Where are you seeing these dropped packets?

 

[Deleted member 138126]

Also, as you've already discovered, Gigabit Ethernet should *always* be set to auto. Anything other than auto has always caused problems in countless different environments I've worked in.

 

[Little_Crow]

Double check the port speed that's been negotiated.
I mention it because when we've repatched our HP ESXi hosts, they've almost always negotiated at 100Mb. Our network guys disable and reenable the switch ports and it renegotiates at 1Gb.
Physically disconnecting and reconnecting the cables generally works too.


Also, how is your teaming configured?
Generally, if it's 1 IP talking to another IP you'll only get a maximum of 1 NIC worth of bandwidth. For resilience or many clients talking to a single server, teaming works perfectly. For increasing bandwidth between 2 IP's it has no impact

There are ways around it, but by far the simplest way is to get 10Gb NIC's (Just not necessarily the cheapest).

 

[nutcase]

Thanks guys looks like I need to do some more reading on teaming as the guides I found didn't mention things like if point to point you still only get the one connection's bandwidth...

Changing the cables had no effect.