Hello, Cybrarians!“Where is your documentation?”This question can be asked by an auditor, a C-Level manager, your boss or a colleague.If you document everything and are methodical in how you work – well done to you.
But for everyone else, well let’s just say procrastination can set in, or we are distracted, we all know the excuses we could wheel out on this.To be clear on where I am going with this, if I want to look at procedures and standards and look at the build of servers, I am going to ask the server team “Where is your documentation?”I could be greeted with many responses “How do you mean? What kind of documentation?” or several others.As a starter - any documentation would be useful.Okay, let’s keep it simple from my perspective, I want to know:
- What applications are on my network
- What servers are these running on
- What OS are these servers
- What patch level are these servers
- What software is installed on these servers, etc.
Is there a list for this information? Probably, but more than likely not in a centralized location.Gathering the info I need isn’t necessarily a problem, but collating it to a central point can be a bit of a pain – more so if I need to rely on others to get me the info, if I don’t have the access rights and they need to dip in and get the info from separate sources then collate it.To save time how do you gather the information?We work in IT, and we like to cheat and cut corners where we can, but only to save time right? With scripting in mind, I came across something recently that is actually quite old. However, there is scope for additions to this. Sydi-Server is a script written by
Patrick Ogenstad. It is aimed at gathering information from an endpoint, typically a Windows OS and collating this info into a user-friendly format, default is an MS Word doc.Having tried this on my local PC, and remote workstations, the information it gathers is useful. For a Windows server, it would provide a helpful snapshot of the hardware, Windows updates, software and other elements as defined by the look-up switches.So what could you use the script for? Putting my risk/audit hat on, I might want to know what servers are in my estate, and what they are running, their patch levels, what other software is running, admin rights to the box etc. In doing so, I have a snapshot in time, and I can quite easily check later for changes. It would be useful for a first build, which once completed, can act as a sign off document to release into the live environment?Having employed this on workstations I have been able to see that AV client and agents are running on a PC, what background services are running, spec the PC etc. For a large estate of PCs, this is not really the tool to use – you would utilize other things, but to give the Server guys a simple tool to help them document what they have – it is gold dust.For smaller organizations, this can be a massive time saver, for larger organizations, one would assume there would be adequate documentation already? If not - take a look anyway and see if it can provide value?Additional information can be gleaned here:
http://ogenstad.net/2006/10/18/how-to-document-servers-with-sydi-part-1-of-3/http://ogenstad.net/2006/10/18/how-to-document-servers-with-sydi-part-2-of-3/http://ogenstad.net/2006/10/18/how-to-document-servers-with-sydi-part-3-of-3/ To get a feel for what it can do, you can run this against your own desktop PC.Download Sydi-Server, and place in a folder.Run a command prompt as Admin and go to the directory with Sydi-Server in.
cscript.exe sydi-server.vbs -wabefghipPqrsS -racdklp -f10 -t 
In the box – put your workstation ID in, if this doesn’t seem to work, try IP address.The above switches will put the output into an MSWord file – be patient when running this.To run against a remote machine, ensure you run the command prompt as an appropriate account with rightsThere are other options to run this as a batch against a host of machines. You could compile into XML, you could maybe run on a server and schedule this.Given the age of Sydi-server, and changes to WMI over the years, it is likely with a little more knowledge and poking around for more information to be obtained with tweaks. For the scripters amongst you, this could be something you could explore – if so I would actively encourage you to feedback to Patrick Ogenstad and help contribute to the community.As with all tools of this nature, make the relevant people aware of what you are doing so as not to trigger alarm bells, or perhaps empower your embattled server guys with a selling point “hey – have you seen this tool?”, if they can see value in it, next time you ask them for the info – they might actually surprise you?Hope you find this useful, and can perhaps see scope to utilize this in your organization perhaps explore and expand the scripts further for the benefit of others?
