SYDI - Network documentation made easy

Limiting the Length of a SYDI Report

Mon, 05 Oct 2009 00:00:00 +0000

Running SYDI-Server using default settings usually generates a Word document somewhere between 20 and 40 pages. While some people hunger for that much information, others are overwhelmed by the details. You might feel that some of the information is irrelevant to your network documentation. If your server documentation template doesn’t include the information, why should your SYDI report?

Sometimes less is more.

I created SYDI with this in mind and you can customize the report quite extensively. Using the -h argument will show all available options for SYDI-Server. cscript.exe sydi-server.vbs -h

Looking through the output you will want to focus on the Gathering Options.

[geek_gibberish]Although all of the information is collected by WMI there are two parameters depending on if the information is found by WMI providers or WMI connecting to the registry.[/geek_gibberish]

By default all options are enabled, so running the script in the default mode is the equivalent to executing:

cscript.exe sydi-server.vbs -wabefghipPqrsSu -racdklp

Create a minimal report you would disable the WMI and Registry options by running:

cscript.exe sydi-server.vbs -w -r

If you would want to include everything aside from installed patches (q, from the help menu), processes (P) and services (s). You would execute this command:

cscript.exe sydi-server.vbs -wabefghiprSu

Since all the options we wanted to disable were those found under the WMI section we didn’t have to touch the –r (registry) parameter.

How to Use SYDI Server with the Windows XP Firewall

Tue, 02 Jun 2009 00:00:00 +0000

If you’re able to run SYDI locally from a computer but you’re not able to reach it over the network. Perhaps with a 462 – The remote server machine does not exist or is unavailable error, this note should interest you. SYDI relies on WMI and the 462 is an error code which has been returned from WMI. You will see this error in two instances, the first one being the machine doesn’t exist i.e. you typed the wrong name or weren’t able to resolve the name. The other instance is that when the target computer isn’t reachable. If your clients are running XP and have the firewall, which was shipped in Service Pack 2, enabled the ports SYDI need are disabled by default.

SYDI relies on WMI which in turn uses RPC communication. RPC starts it’s communication on TCP/135 and then a dynamic port over TCP/1023 is used, this is negotiated between the client and the server.

In order to allow this communication you would have to change the group policy for the machine you are targeting.

In a domain environment you can change this setting under; Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile -> Windows Firewall: Allow remote administration exception. Change the state to Enabled and in the Allow unsolicited incoming messages from field enter the ip address of the machine(s) you will be running SYDI from.

If the machine resides outside a domain you can edit the local group policy by opening up a local group policy from a snap-in in mmc.exe.

Spanish Translation for SYDI-Server

Fri, 29 May 2009 00:00:00 +0000

SYDI-Server collects information through WMI queries and can write a report to XML or Word, which can be used as a server documentation template or as a starting point for your network documentation. When writing output to XML you can use the ss-xml2word.vbs script in order to create a Word file in your language. This is assuming there is a translation file for your language. Carlos de Blas Cartón has created a Spanish file for SYDI. It’s currently available through the translation pack on the download page, but will be included in future versions of SYDI-Server.

Thank you Carlos for contributing to the project! Unfortunately I don’t understand Spanish myself, but I hope others will find it useful.

So now we have nine translation files, the other ones are: Danish, Dutch, English, German, Italian, Norwegian, Portuguese and of course Swedish :)

If you want another language it’s really easy to create one. Just open the lang_english.xml file in notepad and compare it to one of the other ones. Even if you don’t understand the other language you will see what to do.

Server Documentation Template

Fri, 17 Apr 2009 00:00:00 +0000

Not many system administrators purr like a cat when tasked with network documentation. Starting off from scratch doesn’t make things much better. It’s perfectly natural to consult a guide if you’re about to do something you don’t do often. Part of the network documentation project is deciding what you need to include in the final documents. Instead of starting with a blank sheet of paper you can speed up the process by looking at a server documentation template. I see two camps when it comes to network documentation. In the first camp we have people who do network documentation because they have to. Finishing the network or server documentation means they can tick of a task in their todo list. If you are in this camp any server documentation template or checklist will do. If there’s no intended use for the network documentation it doesn’t really matter how it is structured and what kind of information is missing.

In the other camp I see people who would use the network documentation as a tool. This could be to help them and their colleagues to better understand their network, maintain network continuity, help with project planning or a number of other reasons. If you’re in this camp you probably can’t just pick a documentation template and use it as is for your purposes. The key word here is template, you can use the server documentation template as a starting point to build from.

A generic template simply won’t be tailored to your needs, it might contain too much information and details or it could be missing in areas which are critical to you.

I won’t be redundant by writing out everything I think should appear in a server documentation template. Instead I would urge you to run SYDI Server and use the word document it creates as a template. It will probably be too much information in some areas and you will want to add more information to the document. For example it is impossible for SYDI to find information such as system owner and how important a specific server is to the organization.

In the network documentation newsletter I talk more about what you should think about when planning your network documentation.

Which group are you in? How to you use network documentation in your organization?

SYDI-Server 2.3 Released

Sat, 24 Jan 2009 00:00:00 +0000

I’ve just released SYDI Server 2.3.

This is the change log for this release:

Added Product Keys (-rk) for Windows and Office to SYDI Server (based on script by Parabellum
Added Product Key tab in SYDI Overview
Added IP Subnets in SYDI-Overview
Added Errorlevel 999 when script fails to connect to target computer
Added link to patches when viewing xml files in a browser
Added German language file for ss-xml2word.vbs (by Jan Picard)
Removed Copyright character from xml files (bug)

All of the above has been added after getting feedback from users. So if there’s something you want to have implemented there’s a good chance it won’t happen unless you tell me about it.

Anyway I hope you like the new version, if you have any thoughts please post a comment below.

Unknown Runtime Error with Excel 2003

Fri, 19 Dec 2008 00:00:00 +0000

Though troubleshooting can be quite fun at times, at least when your hair isn’t on fire. There are some errors which you don’t want to see i.e. “unknown error, contact your administrator”. When a SYDI user emailed asking me why the network inventory script sydi-overview crashed with unknown runtime error I just couldn’t figure it out since it worked perfectly for me.

Then I remembered that one of the new features in Office 2007 was that in Excel the limitation of 65,536 rows has been removed. Though I like Excel I feel sad for the people who have to have more than 65 k rows in an excel sheet. What I didn’t know but found out was that Excel 2003 also had a limit of 256 columns on a single sheet.

So if you had more than 256 services you will have to upgrade to Office 2007 if you need the tab. If you don’t need the tab but want sydi-overview to work you can run the script with the -t argument:

cscript.exe sydi-overview.vbs -x"path to xml files" -t

I didn’t realize this would be a problem when I wrote the script. If you have fewer than 256 services this won’t be a problem, your other option is Excel 2007.

Since I don’t use Office 2003 I would never have realized this was an issue if someone hadn’t reported this to me. If you experience any issues with SYDI please let me know so I can troubleshoot the issue.

SYDI-Server 2.2 Released

Mon, 01 Dec 2008 00:00:00 +0000

As of today 2.2 is the latest version of SYDI-Server. This version mostly takes care of some small issues.

However I’ve also included a script which lets you audit local group membership across your computers.

These are the short release notes I have for you this time:

Added script sydi-audit-localgroups.vbs to audit local group memberships
Fixed issue with install time for patches on Vista
Fixed bug where subnet mask would appear as destination
Swapped Mb -> MB
Added a Danish language file (by Christian Sandfeld)

The new script sydi-audit-localgroups.vbs is one I’ve been planning on writing for quite some time, then when a SYDI user requested this kind of functionality I threw the script together. It works the same way as sydi-overview.

My plan from the start was to name the sheets after the group names. However Excel didn’t like some of the group names and crashed. So the sheets are named Group1 to GroupX. Run the script and you’ll see what I mean.

Please let me know what you think!

100 000 downloads and counting

Fri, 22 Aug 2008 00:00:00 +0000

Taking a look at the download statistics for SYDI I realize that we just passed the 100 000 download a few days ago. Admittedly the statistic doesn’t look quite as bright as the graph to the left, it’s more of a steady stream of downloads. However I still think it’s great that the number is so high. I hope SYDI has been useful for most of the people who have downloaded it and that it has enabled a lot of networks to be better documented.

Still the download counters are just numbers what really drives me to develop the project is when I hear from you, when I get emails or feedback. I think it’s wonderful to hear what SYDI has done for you.

I love to find posts about SYDI in forums and blogs. It’s really exciting to read what people are saying about SYDI when I’m not involved in the process.

Anyway I just wanted to thank you users for all your support and praise. I hope we see a million downloads and a more structured approach to network documentation. I see room for improvement when it comes to more data which can be collected by SYDI but isn’t today, but also in terms of building a framework for how you can document your network. If you have any ideas you would like to share, please comment below or contact me.

How to use SYDI Server with Login Scripts

Tue, 17 Jun 2008 00:00:00 +0000

Every once in a while I get a question regarding how you can run SYDI from login scripts. My short answer to this is don’t.

Why, you ask?

Because from a user perspective SYDI is slow, this of course depends on how fast your computers are and if you write to XML or Word. Hence running SYDI from a login script adds 15-60 seconds login time for each user every morning. Remember if you have 600 users and it takes 30 seconds additional time to login you’ve just wasted five hours of work, each day. Our job is to help the users to get as much work as possible done each day, if their computer boots up quickly they are happy if it takes too long they get grumpy and unproductive. At best you will get the blame for this at the worst I will!

Secondly in order to get all information from SYDI (under default settings) the user running SYDI needs administrative rights on the machine. This is to collect some of the Disk information. This is another best practice altogether, in short don’t allow the users to be local administrators. If you do anyway be sure not to tell Aaron, he’ll get a fits.

But this is what I want to do!

If you still have your heart set on running SYDI as login scripts I would recommend that you instead use a computer start-up script and that you don’t run the script every day. Make the startup script first check if a SYDI output file for the current computer exists in your repository. If it does make sure that the report is at least 7 days old, then run the script. This way the computer will boot up more slowly once every week instead of every day.

A Different approach

However I still recommend that you rethink the login script strategy. What I would do is to instead schedule a script to run on one of your servers which basically does the same as the “computer startup” script I mentioned. Have a list of all your computers and check when the last report was written, if it is older than the time you specify then run SYDI against that computer. This way the script will run in the background and the users won’t notice it. If they still notice it it’s time to upgrade your machines in a hurry, rush over to Dell. Remember the five hours of wasted work, if your clients are too slow to run SYDI chances are your organization is wasting a lot of productive time just waiting for the computers to load. Create a diagram with sydi-overview and mark all the computers you will need to replace.