Azure Arc (some components still in beta at the time of writing) is a new Azure service that allows you to manage your on-prem or “other” cloud resources with the familiar Azure interface.
But, when I say manage, I don’t think of manage in terms of add disk, increase CPU on a VM – no, you can only certain aspects, like tagging your instances, get the logs so you can use Log Analitycs, assign RBAC controls etc. For more information go to this link.
So, it’s pretty much a governance across different environments as this diagram shows.

In this post, I’ll show you how that looks in practice. I have two VMs in my own vCenter, one Windows and one CentOS Linux. There is no VPN tunnel between the on-prem environment and Azure. We’ll install an agent on both of them and show how that looks like in Azure Arc. Let’s go to the Azure console first and they type Arc in the search bar on top.

As I said, the other components are not in public for everyone, so we’ll go with the Manage servers option. You’ll be presented with this screen. You’ll see your servers here lately. For now, just click Create machine – Azure Arc.

You have two options here. The first one is if you want to add a couple of servers manually and the second is if you want to automate the import with a SPN and a PowerShell script. If you click on Learn more link, you’ll see the instructions. It’s very simple and very straightforward. We’ll go with the first option so click on Generate script.
Select your subscription and the resource group and choose the region. As you can see only 3 regions are supported so far. Specify the proxy if you use it on-prem and select the OS type. Click Review + Generate after.

Before using it for the first time, you have to register first. Click Register and then copy the script below. If you click Download, you’ll get the same script in the file. Once you click Register, you’ll see on the screen that the registration is submitted and you have to wait couple of minutes.

Download the script or copy and paste it in a Windows VM on-prem and run it from a Powershell console with Administrator rights. It pretty much downloads a MSI package and execute it in the background. But, as you can see you have to open a browser and register the VM.

You will also have to enter your Azure credentials after you register your VM. Once you log in, you’ll receive a message that you can close the browser. DO NOT close the PowerShell console, wait for 5-6 seconds until you receive a message – “Successfully Onboarded Resource to Azure”. Now you can close the PS console window.
If you go back to Azure Arc, you’ll see that your VM is there.

For a Linux instance, we’ll use CentOS 7. Do the same as with Windows, add a machine, but this time choose Linux from the dropdown and generate a script. CentOS 7 doesn’t come with wget, so you have to install it first with sudo yum -y install wget. Same thing as with Windows, you’ll have to register the VM.

Again, wait for the confirmation message in the console that the VM is registered and then you can close the Linux session.

Once you finish onboarding, you can go ahead and create the policies, assign rights, monitor the instance and check the logs.
NOTE: The agents communicate over port 443 to a Microsoft site. I am not sure if you can redirect this traffic through a private link. You can check the log file on the Linux machine in /var/opt/azcmagent/log/himds.log. Looks like this in the logs.

{"level":"info","msg":"Send HeartBeat to service via HTTP PATCH @ https://wus2.his.hybridcompute.azure-automation.net/machine/12345678-c3a2-6112-ab89-asdf343dcc307/metadata?api-version=1.0-preview\u0026location=westus2","time":"2020-03-03T16:01:55-05:00"}

If you are behind a firewall and want to access some resources over SSH or RDP, most likely you won’t be able to do that. It’s because most of the corporate firewalls allow only ports 80 and 443 outbound. But you can still bypass that by tunneling everything over port 443. You will need a software called shellinabox to tunnel SSH over 443 and RDP gateway to tunnel the RDP traffic over 443. I’ll present the shellinabox solution for both CentOS 7 and FreeBSD 11. Both of these servers will be sitting somewhere in the cloud or behind your home firewall. The only requirement is to have port 443 opened and accessible on Internet. You might have a public IP or your home firewall will forward the traffic to 443, it doesn’t matter. Another option for connecting to any port is to use putty and a Linux/FreeBSD instance. I’ll describe that option last.

CentOS 7

shellinabox doesn’t come up with the default packages, so you have to install the EPEL release first.

yum install epel-release
yum install shellinabox
systemctl enable shellinaboxd

Edit the configuration file for shellinabox which is /etc/sysconfig/shellinaboxd. Make sure it looks like this.

# Shell in a box daemon configuration
# For details see shellinaboxd man page
# Basic options
USER=shellinabox
GROUP=shellinabox
CERTDIR=/var/lib/shellinabox
PORT=4200
OPTS="--css white-on-black.css -t -s /:SSH:localhost"
#OPTS="--css color.css -t -s /:SSH:localhost"

shellinabox runs on port 4200 by default. You can change it to run on 443, but you have to run as root. A better solution is to install Apache and use the mod_proxy so the Apache will listen on 443 and forward the traffic to 4200.

yum install httpd mod_ssl
systemctl enable httpd

Create the configuration file for the Apache server. In my case, I’ll access the SSH over HTTPS as sshtest.iandreev.com. Change the config below to suit your needs.

cd /etc/httpd/conf.d
touch httpd-vhosts.conf

Edit httpd-vhosts.conf and paste the following.

<VirtualHost *:443>
    SSLEngine On
    SSLCertificateFile /etc/pki/tls/certs/sshtest.iandreev.com.crt
    ServerAdmin klimenta@iandreev.com
    ServerName sshtest.iandreev.com
    ErrorLog "/var/log/httpd/sshtest.iandreev.com-error_log"
    CustomLog "/var/log/httpd/sshtest.iandreev.com-access_log" combined
    ProxyRequests On
    ProxyPreserveHost On
    <Proxy *>
        AuthUserFile /var/www/sshtest.iandreev.com/.htpasswd
        AuthName EnterPassword
        AuthType Basic
        require user ssh.admin
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://localhost:4200/
    ProxyPassReverse / http://localhost:4200/
</VirtualHost>

HTTPS requires a certificate, we’ll create a fake one. If you have a valid certificate, just put it under /etc/pki/tls/certs as sshtest.iandreev.com.crt.

cd /etc/pki/tls/certs
./make-dummy-cert sshtest.iandreev.com.crt

shellinabox when started will give you a SSH prompt so you can login to your server. A more secure solution is to protect the access even more with a username and password. Anytime you access your server, you’ll get prompted with a username and password and then you’ll get prompted with your SSH credentials.

cd /var/www
mkdir sshtest.iandreev.com
cd sshtest.iandreev.com
htpasswd -c .htpasswd ssh.admin
cd ..
chown -R apache:apache sshtest.iandreev.com

I’ve created a user called ssh.admin and the commands above will ask you for a password.
Now, it’s time to start shellinabox.

systemctl start httpd
systemctl start shellinaboxd

On a laptop behind your comporate firewall, go to https://sshtest.yourdomain.com and you should get prompted for ssh.admin’s password. Once you pass that you’ll see the login prompt in your browser. From here you can SSH to any server that has port 22 opened.
shellinabox comes with two styles. If you see above in it’s config, we provided these two lines.

OPTS="--css white-on-black.css -t -s /:SSH:localhost"
#OPTS="--css color.css -t -s /:SSH:localhost"

If you prefer black on white background, uncomment the last line, save the config file and restart shellinabox.
Depending on your CentOS install, you might have firewall and SElinux enabled. If these are not configured, shellinabox won’t work. For the firewall, you’ll have to allow port 443 inbound.

firewall-cmd --add-service=https --permanent
firewall-cmd --reload

For SElinux, you’ll have to allow Apache to make outbound connections.

/usr/sbin/setsebool -P httpd_can_network_connect 1

At the end, it will look like this.

…and this.

FreeBSD 11

We have to install Apache and shellinabox first.

pkg install shellinabox apache24

Make sure they start on boot. Add these two lines in /etc/rc.d

apache24_enable="YES"
shellinaboxd_enable="YES"
shellinaboxd_flags="--disable-ssl --css=/usr/local/www/sshtest.iandreev.com/style.css"

Go to the Apache config directory and edit the config file /usr/local/etc/apache24/httpd.conf. Make sure these lines are uncommented.

Include etc/apache24/extra/httpd-vhosts.conf
LoadModule authn_socache_module libexec/apache24/mod_authn_socache.so
LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so
LoadModule ssl_module libexec/apache24/mod_ssl.so
Include etc/apache24/extra/httpd-ssl.conf
LoadModule proxy_module libexec/apache24/mod_proxy.so
LoadModule proxy_http_module libexec/apache24/mod_proxy_http.so
ServerName www.example.com:80

Go to /usr/local/etc/apache24/extra folder and make sure you have the definitiopn for the virtual host there. Change it to suit your needs.

<VirtualHost *:443>
    SSLEngine On
    SSLCertificateFile /usr/local/share/certs/sshtest.iandreev.com.crt
    SSLCertificateKeyFile /usr/local/share/certs/sshtest.iandreev.com.key
    ServerAdmin klimenta@iandreev.com
    ServerName sshtest.iandreev.com
    ErrorLog "/var/log/sshtest.iandreev.com-error_log"
    CustomLog "/var/log/sshtest.iandreev.com-access_log" combined
    ProxyRequests On
    ProxyPreserveHost On
    <Proxy *>
        AuthUserFile /usr/local/www/sshtest.iandreev.com/.htpasswd
        AuthName EnterPassword
        AuthType Basic
        require user ssh.admin
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://localhost:4200/
    ProxyPassReverse / http://localhost:4200/
</VirtualHost>

In the same directory, edit httpd-ssl.conf file and make sure it looks like this.

SSLRandomSeed startup file:/dev/urandom 512
Listen 443
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLHonorCipherOrder on
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
SSLPassPhraseDialog  builtin
SSLSessionCache        "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout  300

We’ll protect shellinabox with extra username (ssh.admin) and password.

cd /usr/local/www
mkdir sshtest.iandreev.com
cd sshtest.iandreev.com
htpasswd -c .htpasswd ssh.admin

We’ll need a certificate for the HTTPS site. Use your own or create a fake one. Hit ENTER for everything prompted. It’s a fake certificate.

cd /usr/local/share/certs
openssl genrsa -out sshtest.iandreev.com.key 2048
openssl req -new -key sshtest.iandreev.com.key -out sshtest.iandreev.com.csr
openssl x509 -req -days 3650 -in sshtest.iandreev.com.csr -signkey sshtest.iandreev.com.key -out sshtest.iandreev.com.crt

Unlike CentOS, FreeBSD shellinabox doesn’t come up with CSS files for the color, so we can use these two. Copy these files under /usr/local/www/sshtest.iandreev.com as blackonwhite.css and whiteonblack.css.
This is blackonwhite.css. Click to expand.

#vt100 .ansiDefR {
  color:            #ffffff;
}

#vt100 .bgAnsiDefR {
  background-color: #123450;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #000000;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #ffffff;
}

#vt100 .ansiDefR {
  color:            #ffdfd0;
}

#vt100 .bgAnsiDefR {
  background-color: #010203;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #002030;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #1f1fff;
}

This is whiteonblack.css. Click to expand.

#vt100 #cursor.bright {
  background-color: white;
  color:            black;
}

#vt100 #cursor.dim {
  background-color: black;
  opacity:          0.2;
  -moz-opacity:     0.2;
  filter:           alpha(opacity=20);
}

#vt100 #scrollable {
  color:            #ffffff;
  background-color: #000000;
}

#vt100 #scrollable.inverted {
  color:            #000000;
  background-color: #ffffff;
}

#vt100 .ansiDef {
  color:            #ffffff;
}

#vt100 .ansiDefR {
  color:            #000000;
}

#vt100 .bgAnsiDef {
  background-color: #000000;
}

#vt100 .bgAnsiDefR {
  background-color: #ffffff;
}

#vt100 #scrollable.inverted .ansiDef {
  color:            #000000;
}

#vt100 #scrollable.inverted .ansiDefR {
  color:            #ffffff;
}

#vt100 #scrollable.inverted .bgAnsiDef {
  background-color: #ffffff;
}

#vt100 #scrollable.inverted .bgAnsiDefR {
  background-color: #000000;
}

Copy one of them to be your style. Anytime you change the style, restart shellinabox.

cd /usr/local/www/sshtest.iandreev.com
cp blackonwhite.css style.css
cd ..
chown -R www:www sshtest.iandreev.com

Finally, start Apache and shellinabox.

service shellinaboxd start
service apache24 start

Access your server from a laptop behind your corporate firewall as https://sshtest.domain.com.

Windows 2016

You will need a Windows 2016 server with a public IP and port 443 allowed or you can use a Windows server behind your home network as long as port 443 is allowed. In order to bypass the RDP restriction, we’ll tunnel the RDP traffic over HTTPS using Remote Desktop Gateway.
From the Server Manager, go to Add Roles and Features. Select Remote Desktop Services.

Click Next 2-3 times and then select Remote Desktop Gateway. Click Next again and accept all the defaults. Windows will install some other components for you.
Once everything is installed, from the Server Manager’s menu click on Tools, Remote Desktop Services and then Remote Desktop Gateway Manager.
Click on the server name and in the middle pane you’ll see what you have to do.

Click on the first link, View or modify certificate properties. Choose to create a fake certificate or you can import your own. It has to be in p12 format, not PEM.

If you decide to go with a fake certificate, enter the FQDN of the server, e.g sshtest.iandreev.com. You will have to make sure that sshtest.iandreev.com resolves to the public IP of the Windows box or if you have an internal server in your home lab, then the external IP of your cable/DSL modem. Then just click on the button Create and Import Certificate, enter the FQDN sshtest.iandreev.com and then click OK when prompted. Click Apply and OK to go back.
At this point, you might want to create a user or a group that you can allow access to the Gateway.
I created a user called RDP. Back in the RD Gateway Manager, select Policies under the server name, right-click on it and choose Create New Authorization Policies. Choose the option to create both RD CAP and RD RAP policies. Here is what I did in the wizard config.

I choose BUILTIN\Users to be able to use the Gateway. The generic user RDP that I created is by default a member of the users group.

Select the default Enable device redirection for all client devices.
Check both checkmarks for Idle Timeout and Session Timeout. This is optional, but it’s good to have.
Click Next and then create the Resource Authorization Policy.

Accept the same group (BUILTIN\Users).
Choose the option at the bottom, Allow users to connect to any network resource (computer).
Choose the first option, Allow connections only to port 3389.
Click Next and Finish.
So, how do you use this solution now? Easy…
All you have to do is go to your corporate laptop and create a new RDP connection. Under the General tab enter the IP address of the Windows box that you want to reach. This is the box that listens on 3389 and that you are not able to reach directly. Mind that the Windows server that we just built is a gateway, so the Windows RD Gateway server should be able to talk to the destination server over 3389 and your corporate laptop will talk to Windows RD Gateway server over 443.

Click on the Advanced tab and then the Settings button. Select to Use these RD Gateway server settings and enter the FQDN (sshtest.iandreev.com) of the RD Gateway server that we just built.

Once you are done, click Connect and you should get prompted to enter the credentials for the RD Gateway (in my case the username and password for the RDP user) and then you’ll have to enter the username and password for the destination server.
NOTE: Make sure you use .\rdp for the username, not rdp. You can also get an error saying that the identity of the RD Gateway can’t be verified. This is most likely if you messed up the certificate and it doesn’t match the hostname. In that case, the RDP client will allow you to view the certificate. Then copy it to a file and import it on the local machine under the Trusted Root Cert Authorities.

Tunnel over putty

Let’s say that your corporate firewall allows only port 443 outbound. In this case, we’ll build a Linux/BSD server with a public IP and change the SSH listener port from 22 to 443. For this, edit sshd_config under /etc/ssh/sshd_config or /usr/local/etc/ssh/sshd_config. Look for the directive Port 22 and change it to Port 443. Restart the ssh service.
On your client machine behind the corporate firewall, open putty and under Session enter the public IP of your Linux/BSD server and port 443 so it looks like this.

Now, expand the Connection on the left side, then SSH and select Tunnels. For the source port enter 3390 and for the destination enter the IP of your Windows box where you want to connect.

Finally, save this session, open it and login to the Linux server to establish the tunnel. You should be able to run the RDP client (mstsc) and RDP to 127.0.0.1:3390.

In this post, I’ll explain how to configure a rsyslog server and client on various operating systems. For the servers, I’ll chose 2 Red Hat 7 servers and the clients will be AWS Linux, FreeBSD and Windows 2016.
rsyslog is an open-source utility for logging, a derivate of the original syslog. As defined by RFC 3164, each message includes the facility code and severity level.

The severity levels are these. (Both screenshots are from Wikipedia).

RHEL 7 rsyslog servers

RHEL 7 comes with rsyslog installed by default. Make sure it’s running.

systemctl status rsyslog

The configuration file is /etc/rsyslog.conf. Make sure that these lines are uncommented. They tell the rsyslog daemon to accept TCP and UDP connections.

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

If you make changes in /etc/rsyslog.conf, make sure you verify the config.

rsyslogd -N 1

If you make a change, you’ll have to restart the rsyslog daemon.

systemctl restart rsyslog

To test if rsyslog works fine, try a test.

logger -p local0.notice -t from_cmd_line "Test Message"

If you check the /var/log/messages, a file where by default rsyslog writes the output, you’ll see the message.

tail /var/log/messages

OK, so we didn’t have to make any changes on both RHEL servers. Let’s move to the clients.
NOTE: If you have firewalld enabled, you’ll have to open the ports for the clients.

firewall-cmd --permanent --zone=public --add-port=514/tcp
firewall-cmd --permanent --zone=public --add-port=514/udp
firewall-cmd --reload

AWS Linux, RHEL 6, CentOS 6

AWS Linux is based on RHEL 6 so the instructions will apply for all of them. Check if rsyslog is running.

service rsyslog status

Edit /etc/rsyslog.conf and make sure these lines are commented. We don’t want a server, we want a client.

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Add these lines (11 to 14) somewhere at the end.

#$WorkDirectory /var/lib/rsyslog # where to place spool files
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###

*.*     @@10.0.0.170
$ActionExecOnlyWhenPreviousIsSuspended on
& @@10.0.0.225
$ActionExecOnlyWhenPreviousIsSuspended off

# Finally include all config files in /etc/rsyslog.d. This allows overrides
# of the default configuration above.
$IncludeConfig /etc/rsyslog.d/*.conf

These four lines means that my primary rsyslog server has an IP of 10.0.0.170 and in case it’s not reachable, use the server 10.0.0.225. Line 11 tells the rsyslog client to log everything to the server. If you want only certain messages logged, than you can change it, e.g. instead of *.* @@10.0.0.170 you can use something like *.info @@10.0.0.170 or *.info;auth.err @@10.0.0.170. Look at those two tables above. If you run this command on the client.

logger -p local0.notice -t from_aws_linux "Test Message"

and do

tail -f /var/log/messages

on the server, you’ll see the message on the server, not on the client.

FreeBSD

FreeBSD uses the old syslog, not rsyslog, but we can still redirect the logs to our RHEL servers. Edit /etc/syslog.conf and all the way at the end add this line.

*.* @10.0.0.170

As you can see, syslog uses one @, not two @@s. Restart the service and send a test message. You’ll see that the message goes to the RHEL server now.

service syslogd restart
logger -p local0.notice -t from_FreeBSD "Test Message"

Windows

Go to this link and download the rsyslog client. You can see the link for the download and also for the manual.

The rsyslog agent for Windows is very detailed and requires some studying. Use the manual, there are some examples there. I’ll show you how to forward the event ID 7036. This event gets triggered when a service changes its state. So, download the client and open up the GUI. Expand the following and click on Rsyslog. Enter the primary and secondary rsyslog server’s IPs. Click Save in the upper left corner and then click Restart.

If you check the logs on your rsyslog server, you’ll see a lot of logging going on. Pretty much everything that Windows does. We just want to filter all these logs to a single event ID.
So, in the Default Rule Set, click Filters, then right-click AND, choose Add Filter, Event Log Monitor and then Event ID.

Enter the Event ID 7036, click Save and Restart.

Now, go to Services (services.msc) and restart Windows Update service. You should see this on the rsyslog server.

A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. That’s what Wikipedia says.
Today, using certificates is a must. Google search gives you better search scores if your web site is using certificates and if your site is mobile-friendly. So, in this post I’ll describe how to deploy an Enterprise PKI on Windows 2016 server. This post is mostly for on-prem deployments, but it will give you some insights on how PKI works. I will create one Windows IIS web server joined to the domain and one Linux server (not joined to the domain) running Apache. I’ll create SSL sites on both and deploy the certificates, so the clients (Windows machines on your corp domain) won’t get that certificate warning when browsing these site.
In order to do what we planed, we’ll use Active Directory Certificate Services (AD CS). We’ll create a lab with a domain controller, an offline Certificate Authority, an Enterprise Certificate Authority and two web servers. These two web servers (one running IIS and the other running Apache) will host two web sites (test1 and test2) that will have SSL certificates issued by our CA.
The hostnames are :

• dc01.empire.local
• offCA
• entCA.empire.local
• iis.empire.local
• apache

Domain Controller(s)

I won’t explain how to create a domain controller. Just make sure you have a domain controller(s) in your environment. My domain is called empire.local with EMPIRE as a NetBIOS domain name.

Offline Root Certificate Authority

Why do we need an offline Certificate Authority and enterprise CA? It’s per MS best practices. The offline CA will be the one that holds the PKI, but once it’s configured it can be brought offline. The actual certificates will be signed by the enterprise CA. In case the enterprise CA gets compromised, you’ll have to bring the offlince CA on-line and revoke the certificate for the enterprise CA.
So, let’s build the offline CA. This server shouldn’t be part of the domain. Leave it as a workgroup member. From the Server Manager, click on Add Roles and Features.

Select Active Directory Certificate Services.

Under role services, select Certification Authority.

Once the installation is completed, click on the flag icon in the upper right corner to configure the CA.

Choose the defaults or if you want a separate local user, specify it here. You have to create that user first.

Choose to configure Certification Authority.

Choose Standalone CA.

Choose Root CA.

Select to Create a new private key.

Choose SHA256 and 2048. Don’t use SHA1, it’s being deprecated.

Choose the common name for the CA. In my case it’s ROOT-CA.

Use validity for this CA. I used 10 instead of the default 5.

Choose where the database and the logs will be located. I used the defaults, best practice is to use a separate data drive.

Verify everything looks good and click Configure.

Once completed, go to C:\Windows\System32\CertSrv\CertEnroll. This is where you’ll have the root certificate (offCA_ROOT-CA.crt) and the Certificate Revocation List (ROOT-CA.crl).

Go to the Administrative Tools under Control Panel and run the Certification Authority.

Now, we have to configure the Root (offline) CA so it is aware of the subordinate (enterprise) CA. Right click the name of the CA, choose Properties and then click on the Extensions tab. You’ll see something like this.

Click Add and enter the following in the Location field. Then click OK. Don’t click Insert.

http://entCA.empire.local/certdata/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Replace entCA.empire.local with the name of your subordinate (enterprise) server.
After you click OK, check these two checkmarks.

By default, they are not checked. Click Apply and you’ll be prompted to restart the CA service. Go back to the properties of the Root CA, click on the Extensions tab, but this time switch to Authority Information Access (AIA) instead of CRL Distribution Point (CDP).

Same thing here. Click Add and enter the following in the Location field.

http://entCA.empire.local/certdata/<ServerDNSName><CaName><CertificateName>.crt

Replace entCA.empire.local with your enterprise CA server name. Click OK, don’t click Insert.

Then check Include in the AIA extension of issues certificates which by default is not checked. Click OK and that will restart the CA service.
Select Revoked Certiicates, right-click, choose All Tasks and then Publish.

Click OK for the New CRL.

If you go back to C:\Windows\System32\CertSrv\CertEnroll, you’ll see that the time stamp on ROOT-CA.crl file has changed.
Now, we need the root certificate (without the private key) exported so we can copy it to the enterprise CA. Right-click the CA, choose Properties and from the General tab, choose View Certificate.

Click on Details tab and then Copy to File.

In the Certificate Export Wizard, choose the first option (DER).
Click Next and save it under c:\windows\system32\certsrv\certenroll with a name something like this.

Click Save then Finish.

Enterprise (standalone) Certificate Authority

Now, let’s move to the subordinate (enterprise) CA. This is the server that will actually issue and revoke certificates. Make sure this server is a member of the domain.
From the server manager go to Add Roles and Features.

Choose Active Directory Certificate Services.

Choose both, Certification Authority and Certificate Authority Web Enrollment.

Web enrollment will require IIS. Choose defaults.

Once the installation is completed, click on the flag icon in the upper right corner to configure the CA.

Choose the Administrator or some other domain user if you want.

Select the Certification Authority and Certification Authority Web Enrollment.

Select Enterprise CA.

Select Subordinate CA.

Create a new Private key.

Choose SHA256 and 2048.

Choose the common name. In my case it’s ENT-CA.

Choose where to save the request file. This will have to be signed by the Root CA.

Choose defaults. Again, best practice is to save it to a separate data drive.

Verify and click Configure.

You’ll see this warning. This means you have to sign the request file that we just saved under C:\

Now, copy the files from the Root CA (the first server) to Enterprise CA (this server). You will need to copy those three files under C:\Windows\System32\CertSrv\CertEnroll to anywhere on the Enterprise CA server. Choose the desktop, we won’t need them after the configuration. Right click on the certificate file that we created (the one with NO-PVT-KEY in its name) in its name and a .cer as a file extenstion. Click on Install Certificate.

Choose Local Machine.

Choose Place all certificates in the following store.

Click Browse and select Trusted Root Certification Authority.

Click Next and Finish.
Now, go to c:\inetpub\wwwroot\ and create a folder certdata. Remember when we created the CDP and IAI extensions? We used something like http://entCA.empire.local/certdata… Well, we are creating that now. So, create that folder and move the other two files there.

OK, now go back to the offline Root CA. Copy the request file that was created when we installed CA on the Enterprise CA. That’s the file that’s on the C:\ drive of the Enterprise CA. Move it to the desktop of the offline Root CA.
Launch the Certification Authority (Control Panel, Administrative Tools, Certification Authority) and select the name of the Root CA. Right-click, select All Tasks and then Submit New Request.

Browse to the file that we just copied on the desktop.

Click on Pending Requests. You’ll see our request is waiting for approval.

Select the requested item on the right and then right-click, All Tasks and Issue.

The request entry will be gone, but if you click on Issued Certificates, you’ll see the certificate there.

Double-click the certificate on the right and then click on Details tab.

Click Copy to File. In the export wizard choose this option.

Save it on the desktop. I named it as entCA-signed, which will remind me that this is a signed certificate for the Enterprise CA.

Go back to the Enterprise CA and copy this entCA-signed file to the desktop. Then start the Certification Authority (Control Panel, Administrative Tools, Certification Authority). You will see that the CA service is stopped. Right click the enterprise CA name, choose All Tasks and then Install CA Certificate.

Browse to that file entCA-signed that we just copied from the offline Root CA.

Once imported, start the service from the toolbar (green triangle icon). The service should start successfully.

At this point we have to tell the domain controller that there is a new Enterprise CA in the environment. Log to the domain controller, and copy the file (ROOT-CERT-NO-PVT-KEY) from the Enterprise CA. I saved this file on the desktop on Enterprise CA, so do the same. Copy the file from the desktop of Enterprise CA to the desktop of the domain controller. On the domain controller, go to Control Panel, Administrative Tools, then Group Policy Management.
Expand the GP to edit the default domain policy.

Right-click and Edit. Go to Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies and Trusted Root Certification Authorities. Right click on it and choose Import.

Local machine is automatically selected.

Choose the certificate, the one without private key.

The Certificate Import Wizard will launch.

Make sure this is where the certificate will be stored.

Click Finish.

OK, what now? First, delete the files that you don’t need. The ones on the desktop of the Enterprise CA, the domain controller and the offline CA. and the request file on the c:\drive on the Enterprise CA. You can also shut down offline CA. it’s not needed for another 10 years.

IIS Windows Web Server

OK, so we have the PKI in place, but let’s build an IIS web server that uses certificates, which means it will listen on port 443. This web server will be a member of a domain and the URL will be test1.empire.local. Users will access the site as https://site1.empire.local.
Log in to the IIS server and install IIS. This server must be a member of the domain. From the Server Manager add the IIS role.

Create a folder called test1.empire.local under c:\inetpub\wwwroot. Create a text file called index.txt and type something.

Rename the index.txt as index.html.
Start the Internet Information Services (IIS) Manager from Control Panel, Administrative Tools or click on Start then type inetmgr. Right-click on Sites and choose Add Website.

Configure it and click OK.

Once the site is started, make sure that you have the test1.empire.local in the DNS, so the client computers know that test1.empire.local resolves to an IP.

From any machine that’s on the domain, go to http://test1.empire.local. Make sure it works.

Go back to the IIS server. Click on the IIS server name and double-click Server Certificates.

Click on Create Domain Certificate on the right side.

In the dialog box that shows up, fill out the values. The common name is the actual server name.

Click the Select button and specify our Enterprise CA. If you don’t see anything in the certification Authority box when you click Select, it means that the IIS server doesn’t know about the Enterprise CA because the default domain policy is not present. Try with gpforce /update first, to update the domain policy.

Click Finish.
If everything goes according to the plan, you’ll see that you have your certificate issued.

Now, click on the actual web site that we created and click on Bindings on the right-side.

Click on Add button and fill out the values. Pretty much we are telling IIS that we want an SSL site that runs on port 443 with a certificate that we already got from the Enterprise CA.

Now, go back to any client on the network and browse to https://test1.empire.local. You’ll see this.

If you click on the lock icon in the address bar, you’ll see that we got the certificates right.

Apache Web Server

I’ll build a web server running Apache in the environment. I won’t go into details how to do that. Each flavor of Linux/*BSD has its own way of doing it. I’ll use AWS Linux which is based on Red Hat 6. It really doesn’t matter what you use, as long as you know how to configure Apache. Make sure you have the URL in the DNS, e.g. test2.empire.local to resolve to some IP.
For instructions on how to configure Apache on AWS/RHEL6/CentOS 6, you can check my post. For RHEL 7/CentOS chek this link and for FreeBSD use this one.
First, we have to generate the private key for the server. I’ll put it under /etc/certs directory.Do this by typing:

mkdir /etc/certs
cd /etc/certs
openssl genrsa -out test2.empire.local.key 2048

Then we’ll generate a request file that the Enterprise CA will have to sign.

openssl req -new -key test2.empire.local.key -out test2.empire.local.csr

You’ll be prompted to fill out the blanks, similarly with what we did with the IIS server.

Remember, common name is the name of your server URL.
Once you execute these two commands, you’ll have two files under /etc/certs. The private key and the the certificate signing request (.csr extension means that).

The Enterprise CA will have to sign the request file and issue a certificate.
Issuing this certificate is a little bit different. Go to the Enterprise CA and using a browser go to http://localhost/certsrv.

Click on Request a certificate. Then click on advanced certificate request.

Click on the second line, Submit a certificate…

On the Linux/BSD server, open up the csr file under /etc/certs with your favorite editor (vi, nano, vim). It’s just a text file.

Select the text, copy it to the clipboard and paste it under Saved Request field.

For the Certificate Template, choose the Subordinate Certification Authority and click Submit.

Select Base 64 encoded and then you can download the certificate or the certificate chain by clicking the link. In my case, I’ll download the certificate only.

Save the file somewhere on the desktop (delete after use), edit it with notepad, select all and copy. This is how it looks like.

Go back to your Linux/BSD server and edit a new file under /etc/certs. I’ll name my file test2.empire.local.crt, so I know that this is a server certificate. Paste the text from notepad and save it. Edit the httpd.conf or httpd-vhosts.conf or whatever file you have for your web server and create an entry for your web site. In my case it looks like this.

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/certs/test2.empire.local.crt
    SSLCertificateKeyFile /etc/certs/test2.empire.local.key
    ServerAdmin darth.vader@empire.local
    DocumentRoot /var/www/test2.empire.local
    ServerName test2.empire.local
    ErrorLog logs/test2.empire.local-error_log
    CustomLog logs/test2.empire.local-access_log common
</VirtualHost>

Go to the root of your web site, in my case it’s /var/www/test2.empire.local and create an index.html (not .htm) file with something in it.

Finally, go to https://test2.empire.local and you should see the site.

In this post I’ll explain how to install and use AWS CLI. It will be a basic document that will be referred in the following posts. We’ll cover installation on Windows, FreeBSD 10.1 and CentOS 7.0. The installation and basic use is trivial.

Windows

Go to AWS CLI home-page and download your 64-bit or 32-bit version. Double-click the installer and follow up the prompts. I wanted to do some screenshots, but it’s not worth it. Three time click Next, once Install, Finish and you are done. Open a command prompt and type aws. If you see this, you are all set.

C:\windows\system32>aws
usage: aws [options] <command> <subcommand> [parameters]
aws: error: too few arguments

FreeBSD

The aws cli relies on Python, so if you have Python 2.7 installed, do:

pkg install py27-pip

If you don’t have Python installed, use the same command. It will download and install Python 2.7 for you.
If you have a different version, you might want to use the sources.
Then, install aws cli.

pip install awscli

CentOS

Same thing, aws relies on Python. CentOS 7 comes with Python installed. Install pip first.

yum install wget
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install awscli

AWS

Log on to AWS Console and click on Identity & Access Management.

Click on Users and then Create New Users.

Type the username of the first user and make sure that the check mark at the bottom is checked.

Click on Download Credentials and store them somewhere safe. If you lose this file or forget your credentials, you can regenerate the access keys, by selecting the user, clicking on User Actions and then Manage Access Keys.

Now that you have the credentials file downloaded, which is a simple text file, do the following.

aws configure

Enter your Access Key Id, Secret Access Key, Default Region Name and the Default output format (text, table, JSON).

Don’t share these keys with anyone. The keys that I am using are for test use, they are gone by now.

Test the CLI.

c:\>aws ec2 describe-instances

You should receive this.

A client error (UnauthorizedOperation) occurred when calling the DescribeInstances operation: 
You are not authorized to perform this operation.

Go back to the AWS console and back to IAM menu (Identity and Access Management). Create a new group called Admins or whatever you like.

Attach a Policy. In my case, I’ve selected the top option, thus giving the user full admin rights.

Go back to the Users, select the user, click on User Action and click Add User to Groups. Add the user to the group you’ve just created.

Test the CLI again.

c:\>aws ec2 describe-instances

You should see all of your instances, if any.

The default credentials are stored under %UserProfile%\.aws under Windows and ~/.aws under Linux/FreeBSD.

Proxy

If you are behind a firewall and/or you are using proxy, make sure that port 443 (https) is opened. Amazon AWS CLI uses port 443 to execute API calls on the backend. See this page for more details and how to configure proxy.
If you are using FreeBSD and csh/tcsh shell use setenv instead of export.

setenv HTTP_PROXY http://your-proxy-name-or-IP:your-proxy-port

or

setenv HTTPS_PROXY http://your-proxy-name-or-IP:your-proxy-port

I manage a terminal server that Service Desk is using to access some applications using RDP client. Recently, they needed audio enabled. These steps will help accomplish that goal .

First, log to the server and make sure that Windows Audio service is set to start as Automatic instead of Manual. Then, start the service.

Go to Administrative Tools, Remote Desktop and start the Remote Desktop Session Host Configuration. Select the RDP connection, right-click and choose Properties.

In the dialog box, select Client Settings and uncheck Audio and Video Playback.

You’ll get a message that you have to log off and log back on for these changes to take effect.

Also, make sure that you don’t inherit any domain policies that prevent the RDP audio settings. Click Start, Run and type:

gpedit.msc

Navigate to Computer Configuration | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Device and Resource Configuration.

If it says Not Configured or Enabled, it’s fine. If it says Disabled, you’ll have to modify the domain GPO.

Finally, on the client computers, make sure that the RDP client is set to play the audio on the remote machine and not on the server.

Sources:

http://technet.microsoft.com/en-us/library/cc770631.aspx
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004839

In my previous post, I’ve explained how to install vCenter 5.0. In this post, I’ll explain how to upgrade from 5.0 to 5.1. This version brings a new authentication Single Sign On mechanism and a new web client. Check the VMware web site for more information about these new products and features.

First, start SQL Server Management Studio and open the sql script that comes on the vCenter installation media. Single Sign On requires a separate database.

Open rsaIMSLiteMSSQLSetupTablespaces and change the file paths to suit your needs. There are three occurrences of this file path. I used C:\DATA in my case. Click Execute and make sure you get a message that the commands completed successfully.

Click on Security, then Logins and double-click the vpxuser. This is the same user that has full db_owner rights on the vCenter and Update Manager databases. Select User Mapping, RSA (Single Sign On database) and click db_owner.

Now start the vCenter installer and select vCenter Single Sign On.

Click Next.

Create the primary node.

Select the first option.

Enter a password for the admin@System-Domain user.

Select the second option.

Type RSA for the database name, the hostname of the SQL server, vpxuser for the database user and its password.

Confirm that your vCenter server is listed here.

Use the defaults.

Change or accept the defaults.

Change or accept the defaults.

Click Finish.

Next, we’ll have to upgrade vCenter Inventory Service. From the same menu where we launched the Single Sign On install, click on vCenter Inventory Service.

Choose the first option.

Verify that you have the vCenter server name correct.

Change or accept the defaults.

Change or accept the defaults.

Enter the password for the admin@System-Domain user.

Click Install certificates.

Click Finish.

Next, upgrade vCenter.

Enter the password for the vpxuser.

Upgrade the database.

Select the first option.

Choose if you want to use a domain account, local account or system account.

Change or accept the defaults.

Enter the password for the Single Sign On admin user.

Use this log file if you have any issues later.

Click Finish.

Next, we’ll upgrade the Update Manager. Start the installation.

Accept the default option.

Enter the credentials that were used to run the Update Manager service.

Enter the credentials for the vpxuser.

Upgrade the dabase.

Change or accept the defaults. Make sure the vCenter server correctly appears. Click Finish at the end.

Finally, let’s update the web client. You can run the installer from the media or you can just double-click the old client and this message will show up, prompting you to run or save the installer. Just click Run.

Change or accept the defaults.

Enter the password for the Single Sign On admin user.

If you try to use your Windows domain credentials, you’ll have to download the Client Integration Plug-In first. And, that’s it.

In this post I’ll describe how I installed vCenter 5.0 on Windows 2008 R2 server using SQL 2008 R2 database. I’ve used two servers in my lab, one for the vCenter and the other one for the SQL. I won’t explain how to install SQL server, it’s fairly straightforward.

First thing to do is to create the SQL database. VMware provides a SQL script that you can execute to create the database. The script is on the vCenter installation DVD/ISO under source\vCenter-Server\dbschema folder where source is some drive letter (D:\ or E:\). This script does not work right, so we’ll use a modified version. By default, vCenter requires full db_owner rights so it can create some scheduled jobs. If your environment doesn’t allow this type of access, see the installation guide for vCenter. In this post, we’ll grant full db_owner rights for the sql user (vpxuser) to both vCenter database (VCDB) and the msdb system database. Once vCenter is up and running, you can remove the full db_owner rights from the msdb.

Start the SQL Server Management Studio, log as the sa user or some domain user with full SQL admin rights, and click New Query.

Copy and paste the following script, but change the file path where you want your database to reside. In my case it is C:\DATA. Also, change the password for the vpxuser that we will create.

use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'C:\DATA\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'C:\DATA\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_addlogin @loginame=[vpxuser], @passwd=N'vpxuserpassword', @defdb='VCDB',
@deflanguage='us_english'
go
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go

While in SQL Server Management Studio, expand the Security, then Logins. Double-click on the vpxuser and choose User Mapping. Select the VCDB database and put a check mark for db_owner. Put a check mark on the msdb database and do the same (check mark on db_owner).

Next thing to do is to install the SQL Server Native Client on the vCenter server. It’s a free download from Microsoft. Once installed, go to Administrative Tools | Data Sources (ODBC). Click on System DSN tab and then click Add. You should see a SQL Server Native Client 10.0 driver there. Do not use SQL Server driver. It won’t work.

Enter the name for the ODBC connection, a description and type the hostname for the SQL server. In my case, I’ll use vCenter, vCenter Database and sql.

Next, choose SQL authentication and type the SQL user that we just created with the script (vpxuser and its password).

Click the first check mark and select the VCDB database.

Leave the defaults and click Finish.

Click the Test Data Source button and make sure that it says that the connection completed successfully.

Now, it’s time to install vCenter. Insert the DVD or mount the ISO image and the installer will start.

Click the first option vCenter server and go thru the Next, Accept cycle. Once you reach the Database Options, select the second radio button and choose the ODBC connection that we just created.

If you get this error, make sure you start the SQL Server Agent on the SQL server. By default this service is disabled. You can stop this service once the installation completes.

Enter the SQL username and password that we just created.

If you receive the following error, it means that you are not a db_owner on the VCDB database.

You won’t be able to continue until you fix this. When you reach this screen vCenter Server Service, stop. You have an option to run the vCenter Server service as a local server account or you can choose a domain account. If you use a domain account, it should be a local admin on the server.

Change or accept the defaults for the vCenter program.

Select the first option.

Change or accept the default ports. If you install vCenter on a shared server with IIS installed, you’ll have port conflicts here.

Change or accept the default ports for the Inventory Service.

Estimate how many VMs you’ll have.

Click Install.

After couple of minutes, click Finish to complete the install. Your vCenter Server should be up and running, but we are not over yet.

We will install the Update Manager now. This part of vCenter is used to patch the vCenter and ESXi hosts. Log back to the SQL server and in SQL Server Management Studio, execute this script that will create a new database for the Update Manager. Make sure you change the file path for the database. In my case is C:\DATA. We’ll use the same vpxuser user for the Update Manager database.

CREATE DATABASE [VCUM] ON PRIMARY
(NAME = N'vcum', FILENAME = N'C:\DATA\VCUM.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcum_log', FILENAME = N'C:\DATA\VCUM.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCUM
go

On vCenter server, go to C:\Windows\SysWOW64 folder and run odbcacd32.exe. The Update Manager is using a 32-bit ODBC and by default, if you go to Administrative Tools and start the ODBC manager, you’ll execute the 64-bit version.

Pick a name and description for this ODBC connection and specify your SQL server hostname.

Select the VCUM database that we just created and similarly to the previous ODBC creation, finish the rest of the steps.

Start the Update Manager install.

Accept the defaults.

Create a domain user that will run the Update Manager service. In my case I use svc_vcenter.

Specify the 32-bit ODBC connection that we just created.

Enter the same vpxuser and password.

Specify if any proxy servers need to be specified. Update Manager requires Internet connection.

Change or accept the defaults.

The rest of the steps a re just plain Next, Next, Finish.

Once installed, go back and install the vCenter client. I won’t explain how to do this. It’s trivial. Log to the vCenter with a local admin password or with a domain account (if you run vCenter service under a domain account).

Select the top left vCenter server name and then click on Permissions.

Click Add.

Type your domain, enter a user that you want to grant full admin rights and click Check Names. If everything is OK, the dialog box will just blink.

Back in the previous dialog, select Administrator and click OK. We made svc_vcenter an admin vCenter user.

From the vCenter client menu, select Plug-Ins and select the Update Manager plug-in.

Click Run.

Create a new datacenter, add the ESXi hosts and you are all set.

Recently, I was playing with PoshPAIG, a great GUI tool to audit and patch servers. This utility requires a WSUS server and a group policy to “Download updates and do not install” set for the servers. Unfortunately, at my company, our group policy is “Notify for download and notify for install”.
Changing a group policy that will affect over 1000+ servers and not knowing the impact is impossible, so I had to modify the script a little bit to suit my needs. As a matter of fact, the script that PoshPAIG uses to install patches is a modified VBScript version that originates from this site.

First, make a copy of the original Install-Patches.ps1 script that’s in PoshPAIG_InstallFolder\Scripts folder. Then look for the following piece of code:

Insert the following code after “Else” and before “For I = 0…”

'Creating collection of updates to download
Set updatesToDownload = CreateObject("Microsoft.Update.UpdateColl")
For I = 0 to searchResult.Updates.Count-1
    Set update = searchResult.Updates.Item(I)
	Set objCategories = update.Categories
	strCatName = lcase(objCategories.Item(0).Name)
	updatesToDownload.Add(update) 
Next

'Downloading updates...
If updatestoDownload.count = 0 Then
	WScript.Quit
End If
Set downloader = updateSession.CreateUpdateDownloader() 

downloader.Updates = updatesToDownload
downloader.Download()

…or just use the attached file and replace Install-Patches.ps1. Now, when you do the audit, and then install patches, the script will first download the patches from WSUS (it takes a while) and then install them.

Install-Patches

Recently, I had a project to move about 70 printers from one domain member server to another. This was a very easy task, but I had a problem when I had to migrate the network printers on users computers. We don’t use login scripts or group policy to map the printers, so first thought was to visit each user and remap the network printers. But we have about 350+ users and visiting each one was out of the question. I was looking to script this problem and I found a couple of links (see below), that helped me to wrote my own script. After I tested it, we used MS SMS to push this script to every user. Still, there were some minor issues, but we fixed them manually.

This VBscript is very straightforward and it is well commented, so it is very easy to understand.
Click below to download…
addremprtv2

'=====================================================================
'
'
'   Program: AddRemPrt.vbs
'   Version: 2.0    
'    Author: Kliment Andreev
'      Date: 08/22/2008
'
'   Comment: This VBScript will list all network printers in a file
'            on \\LogShare\UserName+ComputerName.txt, then it will add the same printers
'            from a new print server and delete the old ones
'		
'    Note:   1. Printers defined on the new server must be with the same name
'	        or some suffix plus the same name
'	     2. Printers must exist on the new server
'	        e.g \\OldServer\PrinterName must exists 
'		as \\NewServer\PrinterName or as \\NewServer\Prefix+PrinterName
'	     3. Make sure \\LogShare is accessible by everyone for writing
'	     4. This script won't install network printers that are installed as local using TCP port
'		
' Copyright: Public Domain
'
'
'=====================================================================

Option Explicit

dim strOldServer					' Old printserver name, defined below
dim strNewServer					' New printserver name, defined below		
dim strLogShare						' Full path to a share where log files will be created
dim strOldPrinterPath					' Full path (\\servername\printername) of the old printer
dim strNewPrinterPath					' Full path (\\servername\printername) of the new printer + prefix
dim strPrinterName					' Name of the printer only
dim strComputerName					' String that contains the computername
dim strUserName						' String that contains the username
dim strPrefix						' Prefix that will be added to the new printer name
dim objFSO						' Object to work with Files
dim objNetwork						' Object to work with Network Printers
dim objShell						' Object to work with ENV variables
dim objFile						' Full path of the file that contains the printers
dim objOldPrinters					' Object that contains all printers (including local)
dim i, strTemp						' Helper varaibles

Set objFSO = CreateObject ("Scripting.FileSystemObject")
Set objNetwork = CreateObject ("Wscript.Network")
Set objShell = CreateObject ("WScript.Shell")

strOldServer = "USLCPDMGT02"
strNewServer = "USCORPRINTSRV01"
strLogShare  = "\\USCPDITCR01\PrtLogs"
strPrefix    = "CPD_CR_"					

strComputerName = objShell.ExpandEnvironmentStrings("%ComputerName%")
strUserName = objShell.ExpandEnvironmentStrings("%UserName%")
Set objFile  = objFSO.CreateTextFile (strLogShare & "\" & strUsername & " - " & strComputerName & ".txt")
Set objOldPrinters = objNetwork.EnumPrinterConnections

For i = 0 to objOldPrinters.Count - 1
	
	strTemp = UCase(mid(objOldPrinters.Item(i), 1, 2 + len(strOldServer)))
	If strTemp = "\\" & strOldServer  Then
		strOldPrinterPath = objOldPrinters.Item(i)
		strPrinterName = mid(strOldPrinterPath, 3 + 1 + len(strOldServer))
		objFile.Write(strOldPrinterPath & vbCrLf)					' Write \\server\printer to a file
		strNewPrinterPath = "\\" & strNewServer & "\" & strPrefix & strPrinterName
		objNetwork.AddWindowsPrinterConnection strNewPrinterPath			' Add new printer
		objNetwork.RemovePrinterConnection strOldPrinterPath, True, True		' Remove the old one	
	End If

Next

objFile.Close

Useful links:
http://www.hardforum.com/showthread.php?t=806407
http://support.microsoft.com/kb/321025
http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.server.migration/2008-01/msg00011.html