Provided by ArtinSoft, a lead company on the development of migration solutions; this blog is dedicated to information technologies in general. I joined this company on July 2006 as a contractor and I work as a professional trainer on information technologies, mostly for Microsoft's virtualization solutions and ArtinSoft's migration technologies.

August 2006 - Posts

• Adding a duplicated computer to the domain

  We at the virtualization team, have been creating copies of a virtual machine to use them as workstations that will be grouped into a domain. The only problem is that the original virtual machine was not syspreped and apparently this is creating problems joining the domain; this can be seen when new users can not log in the new virtual machine. One quick and easy way that we have found helpful to fix this is changing the name of the computer (to avoid the duplicated name) and moving it to a temporary workgroup at the same time (we couldn't get to rename otherwise). Then we just made the computer reboot, and then moved it back to the domain, and reboot again. After that, it worked just fine. Posted Aug 18 2006, 06:47 PM by smurillo with no comments

• Let Your Script Choose It's Host

  When you are creating scripts to be executed by the Windows Scrip Host, you know there are two applications that could host your script: WScript which is a GUI host or CScript which is a console based host. By default Windows uses WScript, but you can change the default host with a simple command wscript //H:WScript will set WScript to be the default host, and wscript //H:CScript will set CScript to be the host. But what happens if you don't want to get such an ultimatum for all of your scripts. Wouldn't it be nice if you could make your script choose it's own host? I asked my self that question and found this VBScript code online (I couldn't find the original source): ' Forces this script to be run under the desired scripting host. ' Valid sScriptEng arguments are "wscript" or "cscript". ' If you don't supply a valid name, Force will switch hosts. Sub Force(sScriptEng)  If Lcase(Right(Wscript.FullName, 12)) = "\wscript.exe" Then   If Instr(1, Wscript.FullName, sScriptEng, 1) = 0 Then    'Need to switch to CSCRIPT    CreateObject("Wscript.Shell").Run "cscript.exe " & Chr(34) & Wscript.ScriptFullName & Chr(34)    Wscript.Quit   End If  Else   If Instr(1, Wscript.FullName, sScriptEng, 1) = 0 Then    'Need to switch to WSCRIPT    CreateObject("Wscript.Shell").Run "wscript.exe " & Wscript.ScriptFullName    Wscript.Quit   End If  End If End Sub All you need to do is call this procedure at the beginning of your script and it will be ready to go. So, for example: Force "cscript" will force your script to run on the CScript host. A wrong parameter will just force the script to run on the opposite host. Set your scripts free! Posted Aug 18 2006, 01:50 PM by smurillo with no comments

• Remote Virtual Server Object

  We, here at the virtualization team, have been digging around and testing some of the development options you have for the automation of virtualized environments. Developers might be waiting for that famous Microsoft Hypervisor that will be available with Windows Server "Longhorn". In the meantime, there are still tools you can use. The Virtual Server COM API is one of them. You can instantiate this object on a local server where Virtual Server is up and running and you can then have access to its properties and procedures. But if you want to develop something a bit more dynamic you might be interested on creating a centralized management tool for a group of Virtual Servers. This can be accomplished by initializing the Virtual Server Object remotely. Learn more about this by accessing the Virtual Server Programmers Guide, included in your Virtual Server installation. What I want to point out on this entry is that if you are planning to use the remote access, beware you are going to need your Virtual Server on the same domain where the application is running, or as a difficult alternative you can set up a trusted link. Also, the user executing the code must be added to the Administrator's group on the remote Virtual Server. Failing on doing this will lead to runtime security issues that will simply prevent the object from having access to the remote server. Posted Aug 11 2006, 12:53 PM by smurillo with 1 comment(s)