Ogenstad.net

SYDI-Server 2.2 Released

patrick.ogenstad — Tue, 02 Dec 2008 19:11:03 +0000

Yesterday I released version 2.2 of my network documentation tool, SYDI-Server. The new package contains some small fixes, but also a script which lets you audit local group memberships in all your computers. That is local machine specific groups, not domain local groups.

So what you’ll be able to do is to track down all your users running as local administrators, or just find strange groups which shouldn’t appear in your organization.

I’ve also launched a network documentation newsletter for SYDI. This will be my main information channel for SYDI and my writings about network documentation. According to many of its users SYDI is a great tool. I would say it’s a great tool for doing mundane tasks i.e. collecting and presenting information. What I’m saying is that you don’t really need the sydi-server script, it’s just that if you use it you spend 2 minutes compared to several hours. However there’s much more to network documentation than the data collected from sydi-server.

If you like SYDI and want to improve your network documentation be sure to sign up, the newsletter is as free as SYDI.

Though before you sign up you might want to grab the latest sydi-server.

German support for SYDI and the impact of translations

patrick.ogenstad — Tue, 12 Feb 2008 20:35:47 +0000

German has joined the ranks of languages you can use with SYDI-Server. The file will be included in the next version of SYDI-Server. Until then it is available for download through the download page. Thanks to Jan Picard who has made the translation file.

So now we can translate the xml files generated by SYDI-Server to eight different languages. Though this is good if your organization doesn’t use English as its primary language it will mean that in order to keep the SYDI-Server package completely updated I will have to keep in touch with more people and involve more people each time I make a change. This is one of the reasons why there werenâ€t any new features in the core sydi-server script in the 2.1 version.

This is not the way I want it to be, i.e. I see having more translations as a good thing, but still the rest of the project shouldnâ€t have to suffer for it. Because of this I wonâ€t cross mountains in order to get updated translation files for each language since it could delay future releases (more than necessary).

The way I plan to solve this is to create a new package for the translations file and just release those packages more often. That way I can update the English and Swedish files for each release of SYDI-Server and just point to the translation pack for the rest of them.

As always your thoughts are more than welcome, and thanks again to Jan Picard!

Danish Language File for SYDI-Server

patrick.ogenstad — Tue, 05 Feb 2008 21:27:48 +0000

Thanks to Morten Vitved we now have a Danish language file for SYDI. This means we can now translate the XML files generated by SYDI-Server in seven different languages.
The file with be included in the next version of SYDI-Server, until that time you can download it as a patch from the SYDI download page.

If you’re missing your favorite language it’s easy enough to create your own language file. Just open lang_english.xml and one of the other ones in notepad and you should be able to figure out what to do.

SYDI-Server 2.1 Released

patrick.ogenstad — Wed, 30 Jan 2008 06:23:20 +0000

Around 1,5 years has passed since I released SYDI-Server 2.0 and now I’ve finally gotten my act together and released SYDI-Server 2.1!

Most of my work has been concentrated around the SYDI-Overview script and I’ve added a tab which compares services between different computers. I’ve also added an ip address to the overview sheet, however if the machine has two addresses SYDI-Overview will only show one of them. I will look into this in later versions of the scripts.

There are also a few bug fixes.

Anyway SYDI-Server is back again, you can head over the homepage and download it.

The Future of SYDI

patrick.ogenstad — Mon, 17 Dec 2007 21:57:41 +0000

As many of you have pointed out it’s been a while since the last version of SYDI was released. Darrin left a comment saying that the world will need an updated SYDI for new products like Windows Server 2008, SQL 2008 and Exchange 2007.

I have some good news, some bad and some thoughts of the future.

The Good News

First of all the good news, I’m still developing SYDI. I’m working on SYDI-Server 2.1, most of the work is concentrated on the sydi-overview script. I’ve added a service comparison tab where you can compare all services on your machines. I have planned to include installed programs as another tab. Another feature request I’m often asked about, which I want to include in 2.1 is scheduled tasks.

The Bad News

The bad news (from a SYDI point of view) is that my time is very limited, and I’ve chosen to spend my free time in other ways than to code on SYDI. Another issue aside from lack of time is that when I started writing SYDI back in 2004 I was working mostly with Microsoft technology. Though I still work with Microsoft, these days I spend most of my time working with Cisco products. In terms of scripting I’ve written a few cool tools for Cisco devices. So if you like Cisco and if Netsafe, my company, decides to release the tools it might make you happy.

SYDI in the Crystal Ball

So what does the future hold for SYDI, these are things that have not yet come to pass and might not, it depends on the issues I mentioned in the bad news and how motivated I am to spend time working on SYDI. That being said I still love SYDI and want to see it grow.

SYDI-Exchange, I don’t really see much develpment with SYDI-Exchange. My reasoning is that I would like a SYDI-ActiveDirectory instead since a lot of the Exchange information is stored in Active Directory anyway it makes sense. The SYDI-ActiveDirectory would collect all the information needed, and there could be a script for reporting an Exchange organization. Perhaps combining a report based on SYDI-ActiveDirectory with specific server reports from SYDI-Server for the Exchange Servers?

SYDI-ActiveDirectory, what I see for SYDI-ActiveDirectory is perhaps one or two collection scripts and several reporting scripts. This could be reporting for OU structures, Group Policies, Delegation, Exchange, Sites etc.

SYDI-Server, I’m quite happy with SYDI-Server as it is. I have some thoughts on adding more specific information. For example I’ve seen that you can download WMI providers from Dell, it would be cool if you can do some reporting on RAID controllers on Dell servers I haven’t looked closer at this yet though. Reporting from the Security Center would be good to have.

SYDI-SQL, first off I’ve thought of just releasing a 0.9 version and fixing a small bug which makes the script crash for a lot of people. I’ve just not gotten around to it. Other than that SYDI-SQL is probably the script I like the least and I don’t actually use it much myself. What are your thoughts on this? Is SYDI-SQL something you want to see more of?

Visio, generating Visio diagrams from SYDI-ActiveDirectory and SYDI-Server would be cool.

PowerShell, I’ve received some queries about using PowerShell and giving vbscript the boot. The short answer is that I would love to. However there are some issues with PowerShell and Office if you’re living outside the US (or at least if you use non US Regional Settings). There are workarounds but they are a hassle. Before I see a good solution to this problem I won’t be writing any reporting parts in PowerShell. With that being said I have thought of breaking up the scripts in smaller parts. I have thought of having separate scripts for collecting information and writing reports.

XML Format, if you know XML you’re probably not blown away (in a good way) with how I’ve designed the XML format in SYDI. I’ve had some thoughts on throwing the out the old format and creating one that is much more generic. This would help not only me but other people who develop tools for SYDI.

InfoPath, I have some thoughts about the xml files used with ss-xml2word.vbs. As it is now you have to edit the “written” xml file directly in your favorite editor. It might be cool if you could do that in InfoPath or something which would let you see the data as you typed the information. Perhaps this could be done in Word too. I’m not really sure how I want to do it, but all the people in the flash demos I’ve seen on InfoPath seem so happy. Any thoughts?

Database backend, since I started developing SYDI I’ve gotten questions about storing SYDI information in SQL format. My thoughts are that XML is the default format but that it should be easy to convert back and forth between different formats. One thought I’ve had with the database is if you’re just supposed to have one view of your data or if you want to have snapshots so you can go back and forth in time and see when changes occurred. A database could also store the information which is used as the “written documentation” in ss-xml2word.vbs. I want a database design which can include all information about Windows computers, Active Directory and perhaps other aspects of the network. However I don’t want countless tables. Perhaps I need a database design book for Christmas.

SYDI-WindowsMobile, well I have a new HTC TyTN II phone and I have to do some scripting against it. It might not be SYDI though

Licence inventory, I have some thoughts about using the data collected from SYDI to handle licensing for some customers. I’ve thought about having some frontend in MS Access 2007.

Living in the now, better support for Vista & Windows 2008 and other current Microsoft products.

Script Signing, I will be adding digital signatures to the script files I publish in the future.

Network Documentation Guides, in general I want more written tutorials and guides for network documentation on the SYDI Project site. I’ve been planning on writing a few pieces.

Other projects I’ve thought of which might be cool but which aren’t on the map yet; SYDI-PKI, SYDI-Sharepoint, SYDI-ForeFront, SYDI-ISA

SYDI-Linux, if you have any important projects which are depending desperatly on the next version of SYDI-Linux. Well, God help you!

Sorry for not answering your emails!

As I stated earlier, my time is limited and I just haven’t had the time to reply to all the emails I’ve gotten from you users. Still I love getting email from you, though I have to say some days it’s not healthy for my ego.

Anyway I will try to get through my backlog and reply to your emails.

How you can help with SYDI

Darrin also asked about pitching in and giving me a hand with SYDI. Feel free to suggest how you can help and what you are willing to work on. However keep in mind that I might be a bit restrictive with what I decide to add. I don’t like code that I don’t understand or that I’m not able to verify. So if your code depends on some special hardware I might not include it, that is if you don’t ship the hardware to me so I can test it.

Translations, with ss-xml2word.vbs it’s easy to have a localized version of the SYDI-Server report. I’ve received a few which I will be including in SYDI-Server 2.1. If you want support for your favorite language just send me a translated xml language file. Send me an email if you’re unsure of what to do.

Tell your friends, tell your friends about SYDI. Most of my motivation to code on the project comes from seeing how many people use the project also the feedback I get is great. So spread the word.

Link to SYDI, aside from telling your friends another great way to support the project is to have a link to SYDI. So if you have a website or a blog, let other people know that you use SYDI by linking to SYDIproject.com.

What do You want?

If you were sitting in Santa’s lap what would you want from SYDI?

What are your thoughts on this post?

How can SYDI be improved?

What crazy ideas do you have, what would you kill for?

How can the sydiproject.com website be improved? Should there be a section for feature requests? Forums? We have this at the project site at SourceForge, but I don’t really like that format.

Send me an email or better yet leave a comment below so others can comment on your thoughts.

SYDI Articles and Network Documentation Guides

patrick.ogenstad — Wed, 28 Feb 2007 20:43:17 +0000

As I said a while ago I moved SYDI, my network documentation project, to a new domain. Now I’m beginning to add information about SYDI and network documentation in general. The first article is under the best practices section and is titled How to use SYDI Server with Login Scripts.

If you have any requests, please let me know.

Regarding my stories I am going to write more of them and the next installment of The Broken NDA is coming, sorry for the delay!

[tags]sydi,network documentation[/tags]

SYDIproject.com is around the corner

patrick.ogenstad — Fri, 08 Dec 2006 22:16:31 +0000

So the SYDI project is coming of age and will be moving to its own domain. I haven’t launched the site yet but it should be out soon.

My plan is to use Drupal 5 when it is released, which I hope is very soon.

If there is anything you would like to see on the new website please let me know.

The new link to SYDI will be http://SYDIproject.com. Initially the content of the site will match the current one but I have plans to publish more information so hopefully you’ll find the new site more useful.

A few days ago the download counters for SYDI went passed 50 000! Although it’s great to see that so many are using the scripts what I like best about the project is when I receive feedback from you. If you have anything to say about SYDI good or bad just tell me.

[tags]sydi, network documentation, move, drupal[/tags]

How to Document Servers with SYDI – Part 3 of 3

patrick.ogenstad — Wed, 18 Oct 2006 18:14:27 +0000

Wasn’t There an Option for Html?

I might have said there was at some time, but it was a white lie. What you can do is to convert the XML file into a Html document. It’s quite easy and it’s used in this way:

cscript.exe sydi-transform.vbs -xServer.xml -sServerhtml.xsl -oServer.html

Running this script will require that Server.xml and Serverhtml.xsl and sydi-html-stylex.xsl are located in the same directory. If you have created private xsl files you can use the sydi-transform to convert it.

Hey, Wasn’t This about Documentation?

It sure was, most of what we’ve looked at up until now has been more geared against Inventory instead of Network Documentation. I saved the best for last, a new tool in sydi-server 2.0 is the ss-xml2word.vbs script (or SYDI-Server XML to Word).

What the script does is that it takes an XML file and converts it to a Word document. You might be thinking that SYDI already wrote to Word, which is true, however there are situations where that isn’t possible. For example in environments where you don’t have Word installed, may it be in a DMZ or as a scheduled task on a server.

The good part though is the options you specify when creating the Word document. To view these options run:

cscript.exe ss-xml2word.vbs -h

Here you can see that there are two arguments that are required -x and -l.

cscript.exe ss-xml2word.vbs -xServer1.xml -llang_english.xml

This line will create a Word document based on the information in the Server1.xml file, it will then use the English language file which describes what it writes to the Word document. This means that you can have the documentation in your native language. When I released SYDI-Server 2.0 there was support for English and Swedish. Later people have contributed with there own language files which you can download; Italian, Norwegian, Portuguese and Dutch.

One issue that causes the ss-xml2word.vbs script to fail for many people is a path problem. If you run the script and it just writes out a few pages without any information from the xml file and the script crashes, this is happening to you. Either put all the files in the same directory or specify the path after -x -l or -s. I will fix this in future versions so the error message is a bit more user-friendly.

The most exciting feature as I see it is the optional -s argument. This is the reason I created SYDI in the first place. The -s option specifies an XML file which contains the written documentation about the server. That is the documentation you have created, this differs from the data that SYDI-Server has gathered from the machine.

Let’s take it for a spin.

Writing Your Documentation

To get you started I’ve included three files in the Examples directory (of sydi-server), copy the howto.xml and rename it to Server1_docs.xml. This will be where you will write the documentation. Open the Server1_docs.xml file in Notepad. Scrolling up and down you will see different XML tags. You’ll recognize the sections and subsections from the Word documents previously created.

Inside the sections and subsections you will se prenotes and postnotes, inside these there are a few tags. The only thing you have to do in this file is to create and edit tags. Scroll down to the section called toc (Tables of Contents), here you will se the difference between prenotes and postnotes. It has to do where they appear in the final document. Just run a few tests and you’ll se what I mean. So let’s start to document.

In the system info section change this:
In this version you are only able to use text tags, more could be availible in later versions of SYDI.To:

Physical Location: Server Room in Stockholm
System Owner: BOFH
Support Agreement: 3Y Next Business Day (Expires 2007-10-16)
Save the file and create the final document.

cscript.exe ss-xml2word.vbs -xServer1.xml -llang_english.xml -sServer1_docs.xml

The above was just an example, you are of course free to write and include whatever you want in the documentation. If you fail to create the documents it’s good to know that XML parsers are very unforgiving if there’s an error in any of the files. Make sure all tags are closed correctly by opening them in a browser. If you fail to open Server1_docs.xml in a browser the problem is there. Fix it and try again.

I’ve also created a batch file, writedoc.cmd which looks like this:
cscript tools\ss-xml2word.vbs -x\\serverr\net$\sydi\output\%1.xml -llanguage\lang_english.xml -s\\server\itsupport$\documentation-source\%1-written.xml -o\\server\itsupport$\documentation-binder\Server-%1.doc -d -b”Table Contemporary”

I use it by running
Writedoc.cmd Servername

So there you have it, that’s how I use SYDI-Server. If you have any questions just post a comment or contact me.

Read Part 1
Read Part 2

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]

How to Document Servers with SYDI – Part 2 of 3

patrick.ogenstad — Wed, 18 Oct 2006 18:11:39 +0000

The Output Options

SYDI has two output options; one for saving the report and another to choose which format to use.

-o Output to file, specify a path and filename and use quotation marks if there’s a space in the path. Remember to give your file an .xml extension if you’re using the XML format and a .doc extension for the Word format.

-e This is to choose the export format, the default is -ew (Word), to change to XML use -ex.

To create an XML report you would use:

cscript.exe sydi-server.vbs -oServer1.xml -ex [enter]

This will create an XML file that you can open in a browser.

XML Options

You might have noticed that the XML file you created didn’t look that great when viewed in your favorite browser. The reason is that you’re just looking at the raw XML file.

To view a style sheet, use the -s option. I generally use the -sh option which uses the html style sheet included in SYDI. For advanced users there is a -st option where you can specify a style sheet you have created on your own.

Lets test it again:

cscript.exe sydi-server.vbs -oServer1.xml -ex -sh [enter]

In order to view this file with a browser you will need the serverhtml.xsl and sydi-html-styles.xsl to be located in the same directory. These files are in the XML subdirectory of SYDI-Server. Copy the Server1.xml file you just created to that directory and open the file in a browser. Alternatively you can copy all of these files to another directory.

What Other Options do you have?

To be honest, you don’t have that many. The options that are left are -v to check the version of your script; this will check the SYDI website and see if a later version is available (I might remove this option).

The last option is -d for debug, if something fails to run as you expect it might be because of a bug in SYDI. The -d option is useful to troubleshoot these scenarios.

What if You Have More Than One computer?

So you want to run SYDI against multiple computers, it’s easy enough to write a batch file that does it for you. However, in the Tools directory there is a script called sydi-wrapper.vbs. A little “gotcha” is that you have to edit the script for it to work, but don’t panic; there isn’t any voodoo involved. Just open the script in notepad and scroll down to this section:

‘ Gathering Options
‘ WMI – Everything enabled by default
WMIOPTIONS=”-wabefghipPqrsSu”
‘ Registry – Everything enabled by default
REGISTRYOPTIONS=”-racdlp”

‘ Export Options
‘EXPORTFORMAT=”word” ‘ For Microsoft Word
EXPORTFORMAT=”xml” ‘ For XML

‘ Location Options
‘ Location of SYDI-Server.vbs
SYDISERVER=”C:\scripts\sydi-server.vbs”
OUTPUTDIRECTORY=”C:\scripts\Output files\”
LOGDIRECTORY=”C:\Scripts\Log Files\”
TIMEOUT=”600″ ‘ How many seconds you have to wait until a computer-scan is aborted hasn’t been tested.

‘ Other options, check sydi-server.vbs -h for help
‘ Uncoment/Change One of the below
OTHEROPTIONS=”-sh” ‘ For HTML Stylesheet on XML output
‘OTHEROPTIONS=”-b10″ ‘ Base Font size of 12
‘ End Of Settings

You will recognize the -w and -r options, unlike SYDI-Server this script defaults to XML (as it should). What you must change in order to get this to work are the values for SYDISERVER, OUTPUTDIRECTORY and LOGDIRECTORY. If you want to you can change the TIMEOUT value too, however it might not do you any good. That feature seems to have taken time out.

I wasn’t sure this was a good way to implement the script. The reason you have to edit the script is so that you won’t have to write such long commands later on in order to get it working.

Anyway, the remaining options are -u and -p for username and password when you connect to the machines. Then there are the gathering options or source options.

-t Reads from a text file, the computers listed in the text file should be separated by line or comma. To use this option:

cscript.exe sydi-wrapper.vbs -tAllMyComputers.txt

-d This is to get computers from a flat domain (NT4 style) to connect to all the computers in the domain you specify. A word of warning though, I’m told Heaven will be closing the gates for people who use NT4 much longer (you might have to break in as it is).

-a Active Directory, if you just run the script with -a it will connect to the active directory domain where you’re machine is located. Your other option is to specify an LDAP container. SYDI-Server will then scan all computers under this container (except for the ones with disabled computer accounts).

A few examples:

cscript sydi-wrapper.vbs -aDC=exibice,DC=com
cscript sydi-wrapper.vbs -a”OU=Member Servers,DC=exibice,DC=com”

[Self Promotion Mode]
If you haven’t heard of Exibice there’s a whole story about the company, read the first part here and you’ll find the other parts here.
[/Self Promotion Mode]

An Eagles View

After running sydi-wrapper you might have ended up with a whole lot of XML files. To give you a quick overview I’ve included a script for just this purpose. Also in the Tools directory is the sydi-overview.vbs script. It accepts one argument, -x, you will want to point this to the output directory you specified in sydi-wrapper. I have created a batch file which reads:

cscript.exe sydi-overview.vbs -x\\fileserver\net$\sydi\output

Running the script requires that you have Microsoft Excel installed on your machine. The script will parse all the XML files and start to populate the cells in Excel. The script will create six sheets. Computers with basic information about all your computers, WMI Programs is a list of all software installed by Windows Installer, Reg Programs are the ones found in the Uninstall registry key, Processes tells you what every computer is running. All these can be good to detect rouge programs or processes.

Finally there is the OS distribution pie chart and data source.

Read Part 1
Read Part 3

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]

How to Document Servers with SYDI – Part 1 of 3

patrick.ogenstad — Wed, 18 Oct 2006 18:08:59 +0000

Having written SYDI from scratch, I know it inside and out. Unfortunately I don’t think I’ve managed to communicate how SYDI works in an efficient way. The readme file included in SYDI is far from perfect. While people in this line of business can usually figure out how it works, others will just ignore reading the manual anyway. In this how-to I will go through the basics of how SYDI-Server works and then describe how I use SYDI-Server.

Getting the Software

You probably have the software already, but just in case. Download it from the SYDI website, or if you love this site and don’t want to leave it no matter what: you can download it from here. This guide is written for SYDI-Server 2.0, if there is a newer version when you read this, don’t worry; it should be useful anyway. Just be sure to check the changelog.txt file for new features.

Unzip the file to your target directory.

Running SYDI in default mode

To see what the software does, open a command prompt and navigate to your sydi directory. This step requires you to have Microsoft Word installed on your computer. Type the command:

cscript.exe sydi-server.vbs [enter]

A message box appears and asks you which host you want to target, the default is localhost. You can select another host if you have administrative access on that machine. Though for now, just press enter.

In the command prompt window you will now see that SYDI starts to gather information about your machine. Soon a Word document is created and SYDI writes the information gathered into the document.

Take a look at the document. Not all this information will be relevant to you and you can remove the parts you don’t want by reading further. Close Word, or save the file it if you want to.

The Options

To view the available options use the help command (-h):

cscript.exe sydi-server.vbs -h [enter]

Options in five categories will be listed; Gathering, Output, Word, XML and Other. In reality there are only two, Gathering and Output.

Gathering the Information

Breaking down the gathering option we have five different arguments -w for WMI options, -r for Registry options and -u and -p for username and password if you want to connect to a different user. Finally we have the -t option where you specify which host you want to target against.

Looking closer at the -w argument from the help menu (-h) you could see that SYDI defaults to using -wabefghipPqrsSu, meaning everything gathered from the WMI providers will be included.

You cannot remove everything from the report, but let’s create a document without all the extra information. Run:

cscript.exe sydi-server.vbs -w [enter]

As you can see the report created is much shorter than the previous one. We have removed the optional WMI providers, but we still have the basic ones and the information coming from the Registry.

To choose which options you want, just check the help menu and see what they mean. If we want to add Bios Information, Printers and Services we would run:

cscript.exe sydi-server.vbs -wbps [enter]

This way you can pick and choose the options you want. The Registry switch works the same way. For an even smaller report you can run:

cscript.exe sydi-server.vbs -w -r [enter]

Now you can add the registry options that you want. Please note though that a lot of the “Computer Roles” are gathered from the Windows Components, so if you want these roles you must have the Windows Components in your report (-rc).

Using the -t option removes the message box asking you which host you want to target. A few examples of using the -t switch:

cscript.exe sydi-server.vbs -tServer1
cscript.exe sydi-server.vbs -tDC1
cscript.exe sydi-server.vbs -tWebServer
cscript.exe sydi-server.vbs -t192.168.0.10

The user and password options should work as you would expect them to, if they don’t: report the bug to me

Word Options

As you’ve seen, sydi-server defaults to writing output to Word. The reason for this is so that you can get a quick overview of what the script can collect without having to do any tricks. Having said that, I only use the Word option to get a quick view of a machine, later I throw away the document. I always use the XML format which I later convert to a Word document, more on that later. Even though you won’t use the Word options much we’ll just take a quick look at them to see what you can do, it won’t be a total waste as a few of the options are used by another script called ss-xml2word.vbs.

-b is for the border of the tables created in the document. As you might have noticed there isn’t any borders by default (when you print the document). You can use all borders you have installed in Word. To test it, type:

cscript.exe sydi-server.vbs -b”Table Contemporary” [enter]

-f is if you want different font sizes, the default font size for the text is 12. To change it, use:

cscript.exe sydi-server.vbs -f8

-d tells SYDI not to display Word until the entire report is written. Using the -d option makes the process go faster. Also if you want to save the file (-o option, more on that later), you might not want to see Word at all. For example if you are running a scheduled task you don’t want a GUI to be loaded.

-n will remove all the text inside the brackets, such as “Logical location: [provide info: Server VLAN 2]”. This way you won’t have a bad conscience about not completing the documentation. But as I have already stated, the whole idea of sydi-server writing directly to word is obsolete. If you start changing the document after it is created and want to run SYDI again your changes will be lost, or you will have to cut and paste them to the new document. There is a way around this though (hint: continue reading!).

-T This is if you want to specify a corporate Word Template file (.dot), which enables you to choose which fonts you want to have as well as their size. This way you can get your “look and feel” in the document.

Read Part 2
Read Part 3

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]