NetWorker media request: (critical) Waiting for 0 writable volume(s) to backup pool ‘Daily’ tape on <server name>

Huh?  I suppose strictly I should go and remove all writable volumes(s) from the pool

First do your normal find & replace to catch anything in the “normal” layout section. The following code example can then be used to search though each textbox in turn:

1
2
3
4
5

For $j = 1 To $oDoc.Shapes.Count ;For 1 to total number of textboxes
	$oDoc.Shapes($j).Select ;Select Text box $j
	$oDoc.Application.Selection.WholeStory ;Select content of textbox
	$oFind = _WordDocFindReplace($oDoc, "01924", "xxxxxx",2,-1) ;Find in current selection
Next

And yes $oDoc.Application.Selection.WholeStory is real! It selects the content inside the text box. The -1 parameter of the _WordDocFindReplace tells it to search just the current select. Using 0 will cause _WordDocFindReplace to select all the normal content and search that, ignoring the textbox

As for disabling Macro’s (for example if you want to stop any automatic macros from firing when open a document) you can use:

1
2

$AutomationSecurity=$oWordApp.Application.AutomationSecurity ;Save Settings
$oWordApp.Application.AutomationSecurity=3 ;Disable Macros

To restore the settings use

1

$oWordApp.Application.AutomationSecurity=$AutomationSecurity

Hope someone out there finds this useful.

Basically allows you to draw diagrams of you’re network, and it takes data from the rrd files and displays different coloured arrows show the percentage of the link used.

Basically allowing you to see whats going on, on your network and where all the traffic is going/coming from

When I cam back Microsoft file search was still going but showing thousands of copies of one these silly name the item thing. I tried to delete them but couldn’t. Tried to open them – couldn’t. Opened the folder and the file was there, tried to open and delete said item but couldn’t. I then took a look at the location and it dawned on me.

In Microsoft infinite wisdom when you open the actual folder contain the recycle bin items, it does some background trickery and shows no matter who’s recycle bin you look at the content of you’re own (unless using commands line etc). It seems this also applies to search for files. As nearly all our users have recycle bins it had searched them (and looked in mine) found this file and shown it up, thinking that it was contained in this folder.

It had ruined my search, so I ended up emptying my recycle bin and starting the long search process again.

It appears after someone other Hospital installed SMS to our new domain at forest level, and didn’t enter in any boundaries, nor exclude servers SMS has ended up on all of the new Citrix serves.

This wouldn’t be too bad if it wasn’t for the fact it’s made logon/logoff synchronise – so you have to que to login, hence some very mysterious pauses in the while process. The usuall debugging tricks didn’t help either. It took a trip to the citrix website and a search of the forums to come up with a couple of MS article on the problem (this affects plan Terminal Services servers too….)

What I have tried is to upgrade the client to the latest version and the home the dam thing to our own system so it won’t slow it down network wise (its on a neighbouring switch – one of them connects to the gig link on the other at present, on the same vlan). Plus it appears to have stopped queuing logons/logoff and just gets on with them. Either that or the client isn’t active enough. I’ll just have to keep an eye on them for when they restart.

So remember when pushing out SMS clients on big multi domained networks – define boundaries before pushing the bloody clients out – and don’t give the bugger rights to everyone in the forest if that isn’t what you want. Oh and defiantly don’t install them on servers without checking on any performance hits or operational differences it may cause.