You can use SQL Studio Express to administer the Windows Internal database. Just point the SSE to:

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

And Bob is your father’s brother. Also, I know that this is not news. It’s just easier to copy and paste, and I can always find it here. ;)

I passed 70-649 today, to update my MCSE 2003 to Windows 2008.
So now, I’m an MCTS. I *was* an MCSE +Security +Messaging.
Somehow, MCTS doesn’t seem as impressive.

Recently, I needed to install Firefox-3.5.3 on multiple workstations in an Active Directory domain. Rather than create MSI packages and assign the application with Group Policy, I used Psexec and batch scripts to push it out. Here’s how:
If you don’t have Psexec installed, you can download it from Microsoft here: http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx
Next, download the installer you want to use. In this example, we’ll use Firefox. Make a share on your server that all users can read, and place the installer inside the share.
So now, we’ve got \SERVERNAMESHARENAMEFirefoxInstaller.exe
Next, you need a few files to make this happen:
1. UpdateClients.bat
2. hostnames.txt
3. SoftwareInstaller.bat
All of these files need to be in the same directory, and you must have administrative privileges on the workstation you wish to update.
Basically, the UpdateClients.bat file enumerates the hostnames.txt, and passes the hostnames of the workstations/servers found in it to the SoftwareInstaller.bat file. Here are the contents of the files:

1. UpdateClients.bat


for /f "tokens=*" %%a in (hostnames.txt) do SoftwareInstaller.bat %%a


2. hostnames.txt (one hostname per line)


hostname1
hostname2
hostname3


3. SoftwareInstaller.bat


SET SERVERNAME=replacewithservername
SET SHARENAME=replacewithsharename
echo "checking for Installers directory on the target..."
if not exist \%1C$installers mkdir \%1C$installers
if not exist \%1C$installersfirefox353 mkdir \%1C$installersfirefox353
echo "copying Firefox install to install directory..."
xcopy "\$SERVERNAME$SHARENAMEFirefoxInstaller.exe" "\%1C$installersfirefox353" /e /y
echo "Installing Firefox..."
psexec.exe \%1 "c:installersfirefox353Firefox353.exe" -ms
echo "Firefox Done."


Now, fill the hostnames.txt with your hostnames, and double-click UpdateClients.bat.

Sometimes, too many people have messed with it.
Plain and simple.
People like to check boxes. And enable/disable things. it’s fun.
But when it’s your CAS server, it can be a real hassle to navigate the IIS interface, and reset all of those little “tweaks”, placed there by someone with apparently no business “tweaking” IIS.
You know who you are.
;P

In these cases, it’s much easier to let Exchange do it for you, and all you need to open is the Exchange Management Shell.

This will list all the current OWA-related virtual directories.

get-owavirtualdirectory

This will delete the OWA virtual directory for the Default Web Site.

remove-owavirtualdirectory -identity "owa (Default Web Site)"

This command will re-create the owa virtual directory under the Default Web Site in IIS.

new-owavirtualdirectory -OWAVersion "Exchange2007" -Name "owa (Default Web Site)"


This command will re-create the “Exchange” virtual directory under the Default Web Site in IIS.

new-owavirtualdirectory -OWAVersion "Exchange2003or2000" -VirtualDirectoryType "Mailboxes" -Name "Exchange (Default Web Site)"


When you run this command, if you get an error similar to the one below, it is possible that IIS is set to work in 32 bit mode and not the required 64 bit mode.

New-OwaVirtualDirectory : An error occurred while creating the IIS virtual directory ‘IIS://mailserver.yourdomain.com/W3SVC/1/ROOT/owa’ on ‘mailserver’.
At line:1 char:24
+ New-OWAVirtualDirectory <<<< -OWAVersion "Exchange2007" -Name "owa" -Website "Default Web Site"

To make IIS run in 64 bit mode, run the following in an administrative command prompt:

cscript %SYSTEMDRIVE%inetpubadminscriptsadsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

THIS UPDATE WAS SHAMELESSLY RIPPED FROM http://my.opera.com/ravenoverride because if I have to spend another 2 hours searching for the correct command to add these to the proper site name, I’ll snap.

Remove-OWAVirtualDirectory -Identity “Owa (XXXXXXX)” -Confirm:$false
Remove-OWAVirtualDirectory -Identity “Exadmin (XXXXXXX)” -Confirm:$false
Remove-OWAVirtualDirectory -Identity “Exchange (XXXXXXX)” -Confirm:$false
Remove-OWAVirtualDirectory -Identity “Exchweb (XXXXXXX)” -Confirm:$false
Remove-OWAVirtualDirectory -Identity “Public (XXXXXXX)” -Confirm:$false
Remove-WebServicesVirtualDirectory -Identity “EWS (XXXXXXX)” -Confirm:$false
Remove-ActiveSyncVirtualDirectory -Identity “Microsoft-Server-ActiveSync (XXXXXXX)” -Confirm:$false
Remove-OabVirtualDirectory -Identity “OAB (XXXXXXX)” -Force:$true -Confirm:$false
Remove-UMVirtualDirectory -Identity “UnifiedMessaging (XXXXXXX)” -Confirm:$false
Remove-AutodiscoverVirtualDirectory -Identity “Autodiscover (XXXXXXX)” -Confirm:$false

To verify that the directories have been removed, run the following commands. You should receive no output:

Get-AutodiscoverVirtualDirectory
Get-OABVirtualDirectory
Get-OWAVirtualDirectory
Get-WebServicesVirtualDirectory
Get-ActiveSyncVirtualDirectory
Get-UMVirtualDirectory

To properly create these virtual directories, run the following commands (Please keep the information what you got earlier for XXXXXXX and change it here to):

– Open Exchange Management Shell with elevated permission
– Run the following commands (THE COMMANDS ARE A ONE-LINER. THE NEXT COMMAND IS SEPARATED WITH —————————–. So copy and paste it into notepad, check if it is one line, read it carefully and change the information you have to provide. Information you have to provide is in BIG LETTERS or XXXXXXX):

New-OWAVirtualDirectory -WebsiteName “XXXXXXX” -OwaVersion “Exchange2007”
-ExternalAuthenticationMethods Fba
—————————–
Set-OWAVirtualDirectory -InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/owa/”
-ClientAuthCleanupLevel “Low” -LogonFormat “UserName” -DefaultDomain “NETBIOSDOMAINNAME”
-Identity “Owa (XXXXXXX)”
—————————–
New-OWAVirtualDirectory -WebsiteName “XXXXXXX” -OwaVersion “Exchange2003or2000”
-VirtualDirectoryType “Exadmin” -ExternalAuthenticationMethods Fba
—————————–
New-OWAVirtualDirectory -WebsiteName “XXXXXXX” -OwaVersion “Exchange2003or2000”
-VirtualDirectoryType “Mailboxes” -ExternalAuthenticationMethods Fba
—————————–
New-OWAVirtualDirectory -WebsiteName “XXXXXXX” -OwaVersion “Exchange2003or2000”
-VirtualDirectoryType “Exchweb” -ExternalAuthenticationMethods Fba
—————————–
New-OWAVirtualDirectory -WebsiteName “XXXXXXX” -OwaVersion “Exchange2003or2000”
-VirtualDirectoryType “PublicFolders” -ExternalAuthenticationMethods Fba
—————————–
New-WebServicesVirtualDirectory -WebsiteName “XXXXXXX”
-InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/EWS/Exchange.asmx” -basicauthentication 1
-windowsauthentication 1
—————————–
New-ActiveSyncVirtualDirectory -WebsiteName “XXXXXXX”
-InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/Microsoft-Server-ActiveSync”
-ExternalAuthenticationMethods Basic -InternalAuthenticationMethods Basic
—————————–
New-OabVirtualDirectory -WebsiteName “XXXXXXX” -InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/OAB”
—————————–
Set-OabVirtualDirectory -PollInterval “30” -Identity “oab (XXXXXXX)”
—————————–
New-UMVirtualDirectory -WebsiteName “XXXXXXX”
-InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/UnifiedMessaging/Service.asmx”
—————————–
New-AutodiscoverVirtualDirectory -WebsiteName “XXXXXXX”
-InternalUrl “https://INTERNAL_FQDN_OF_EXCHANGE/Autodiscover/Autodiscover.xml”
-BasicAuthentication 1 -WindowsAuthentication 1
—————————–
Set-ClientAccessServer -Identity “Servername”
-AutoDiscoverServiceInternalUri “https://INTERNAL_FQDN_OF_EXCHANGE/Autodiscover/Autodiscover.xml”
—————————–
Set-OfflineAddressBook “Default Offline Address Book”
-VirtualDirectories “ServernameOAB (XXXXXXX)” -Versions Version2,Version3,Version4)”

– To check if we were successful in creating the virtual directories correctly type in the commands:

Get-AutodiscoverVirtualDirectory
Get-OABVirtualDirectory
Get-OWAVirtualDirectory
Get-WebServicesVirtualDirectory
Get-ActiveSyncVirtualDirectory
Get-UMVirtualDirectory

For example, you should receive the following for Get-OWAVirtualDirectory

Name Server OwaVersion
——– ——- ———–

Owa (XXXXXXX) Server Name Exchange2007
Exadmin (XXXXXXX) Server Name Exchange2003or2000
Public (XXXXXXX) Server Name Exchange2003or2000
Exchweb (XXXXXXX) Server Name Exchange2003or2000
Exchange(XXXXXXX) Server Name Exchange2003or2000

– Then run the following commands to disable the Kernel Mode Authentication on EWS, Autodiscover, and OAB virtual directories (THE COMMANDS ARE A ONE-LINER. THE NEXT COMMAND IS SEPARATED WITH —————————–. So copy and paste it into notepad, check if it is one line, read it carefully and change the information you have to provide. Information you have to provide is in BIG LETTERS or XXXXXXX):

cd $env:windirsystem32inetsrv
—————————-
.appcmd.exe unlock config “-section:system.webserver/security/authentication/windowsauthentication”
—————————–
.appcmd.exe set config “XXXXXXX/ews” “-section:windowsAuthentication” “-useKernelMode:False” /commit:apphost
—————————–
.appcmd.exe set config “XXXXXXX/AutoDiscover” “-section:windowsAuthentication” “-useKernelMode:False” /commit:apphost
—————————–
.appcmd.exe set config “XXXXXXX/oab” “-section:windowsAuthentication” “-useKernelMode:False” /commit:apphost

– Run: iisreset /noforce

– You must rerun the Internet Address Management Wizard to stamp the new virtual directories with the proper external URL and maybe you have to check the certificates.

Give up?
It’s time to upgrade your version of Windows!!
http://www.us-cert.gov/cas/techalerts/TA09-209A.html
If you don’t know what that means, you’re in trouble. Yes, you.
Basically what this says is that EVERY version of Internet Explorer on every version of Windows is vulnerable to a Remote Code Execution exploit. (in English, that means that Mr. Bad Guy can run *ANY* program he wants on your computer with full administrative privileges. This of course, being in direct violation of Rule #1 of the 10 Immutable Laws of Computer Security.)
The patches will implement a kill-bit, and disable parts of COM and ActiveX controls, p(robably)ossibly breaking legacy applications.

The solution?
Run out ->don’t walk<- and buy the latest copy of the Microsoft Windows 7 Operating System. Oh. Sorry. You can't get it, just... yet... It's coming, though.. Microsoft Partners will see it in about 2 weeks, and it will be available to the general public some time in October. The attack vectors are not only via Internet Explorer. Any application (such as MS Office) with access to ActiveX and/or COM objects can exploit this vulnerability. Here’s the bulletin. Extensive testing is suggested if you use ActiveX controls or COM objects in mission-critical applications.

First, you need to download SubInACL.

SubInACL is a command-line tool that allows administrators to obtain security information about files, registry keys, and services. It also allows you to transfer this information from user to user, from local or global group to group, and from domain to domain.

Next, create a file with the name regperms.cmd under C:Program FilesWindows Resource KitsTools folder

Now you need to Edit the regperms.cmd file and add the following lines

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=system=f

Save and exit the file

Now, you need to open a command prompt and run the following command:

cd “C:Program FilesWindows Resource KitsTools”

After this, press enter and then run this command:

regperms.cmd

After entering this, press enter. After a few minutes of processing by subinacl, the permissions will be reset. Reboot, and enjoy!

I found this *AWESOME* website while testing an Exchange 2007 server for an ActiveSync issue. Thanks, Microsoft!
https://www.testexchangeconnectivity.com/

Lately, I’ve been ripping out and replacing antivirus software in the Enterprise. Funny thing is, most of these types of software do not have a remote uninstall utility. Being the famously lazy admin I am, I had no interest in logging into each workstation, and manually removing it.

Instead, I used psexec. It’s just one command in an awesome toolset written by Mark Russinovich called Pstools. So, I saved the following as a batch file, and executed it against all domain workstations. Here’s the contents of the symantec_removal.bat file:


REM save this as c:symantec_removal.bat
@reg add HKLMSOFTWAREIntelLANDeskVirusProtect6CurrentVersionAdministratorOnlySecurity /v UseVPUninstallPassword /t REG_DWORD /d 0 /f
@reg add HKLMSOFTWAREIntelLANDeskVirusProtect6CurrentVersionAdministratorOnlySecurity /v LockUnloadServices /t REG_DWORD /d 0 /f
msiexec /norestart /qn /x{46B63F23-2B4A-4525-A827-688026BE5E40}


Then, just install pstools into your PATH, and open a command prompt on the server, and do this:

psexec \* -c c:symantec_removal.bat

You’ll notice that the msiexec command has a GUID, so if your version of Symantec is different than mine, you’ll need the correct GUID for your version. This can be found here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Just look through the GUIDs located here until you find your version of Symantec. Then, just replace {46B63F23-2B4A-4525-A827-688026BE5E40} with the GUID found in your registry.

BTW – The first 2 lines in that batch file are for removing the uninstaller password from symantec antivirus. If you don’t use an uninstall password, you can remove them.

I wrote (swiped and altered) this script to check for a Symantec Uninstaller password. You might notice that it’s very similar to the Remote Desktop script I posted a while back. Still it works, and saves some time, so here it is:

symantec_uninstall_password_checker.bat

Recently, I needed to determine which local LAN hosts were infected with spyware on a network of Windows XP computers. This network is a single Active Directory Forest, with a single ‘domain.local’ domain name.
In the absence of any anti-spyware management tools, I decided to use the DNS server on the domain controller to help me determine which workstations were infected.

First, I changed the outbound forwarder servers to use OpenDNS. OpenDNS is a free recursive DNS service that you can use to resolve all DNS queries on the Internet safely. The reason for this is that the OpenDNS servers will re-direct your infected machine’s traffic away from known botnets and known distribution points for spyware to their own, essentially cutting off an infected workstation’s access from known “bad guys”.

Usually, when I implement the OpenDNS service on a LAN, I notice an *INSTANT* improvement in available bandwidth.. Try it for yourself. More info here: www.opendns.org

Next, you need to clear the cache on your DNS server. To do this, open DNS Management in your MMC, right-click the server, and click “Clear cache”. Now, click “View”, and “Advanced” in the MMC’s menu, and you can now view the cache.
Right-click the server again, and click “Properties”.
On the “Logging” tab, turn on “Debug Logging”, note or set the location of the log to be written.
Now, right-click the server, and click “All Tasks” -> “Restart” to restart the DNS service.
Since most spyware infected hosts need to phone home on a regular basis, you can now just watch the cache for incriminating lookups, and read the DNS debug log for the IP address of the offending hosts.
Anyway, it worked for me, and I was able to identify the 3 hosts on the LAN that had spyware infections, in about 10 mins… (without staring at a protocol analyzer…)

Note: Do not forget to turn the DNS debug logging off again when you are finished. This logfile will grow *very* quickly, and become difficult to open or manage within hours on a busy LAN.