PowerShell and Scheduled Tasks

I have been setting up some schedule PowerShell scripts through the Task Scheduler; however, I was having a bit of trouble with one of the scripts. 

The script would run perfectly if I ran it manually, but when I ran the task nothing would happen. As you might know this is a bit of a problem because schedule tasks don't not show the console, and won't allow you to see the errors. The Task's log are not very helpful either.

What helped me troubleshoot the problem is this little cmdlet:

Start-transcript -path C:\Temp\Filename.txt

Placing that command at the beginning of your script will create a transcript file. The transcript file will contain everything that would print into the console, and it should look a little like this:

-------------------------------------------------------------

**********************
Windows PowerShell transcript start
Start time: 20141114101902
Username  : DOMAIN\S.AD.Util 
Machine  : HOSTNAME (Microsoft Windows NT 6.3.9600.0) 
**********************
Transcript started, output file is C:\Temp\Transcript_11-14-2014.txt

ModuleType Version    Name                        ExportedCommands     
---------- -------    ----                        ----------------     
Script     1.0        tmp_scev4zye.pet          {Get-DServerSetti...

-------------------------------------------------------------

If there is any errors they will show here, even if they are not stopping errors. Which is great because at one point my script was sending the email and successfully completing, but failing to create the report all together and sending a blank email.

I hope this might help someone out there! 

Update: Locked accounts

This post is related to a previous post.

We have recently been receiving several incidents regarding accounts that are getting locked out. Our Service Desk and Desktop team have been unable to find the cause and so they escalated to us. Following the log trail we have found that this devices are normally getting locked out in our CAS server. This was easy enough to be determined by using a Microsoft tool called Lockoutstatus; however, we had been unable to determine exactly what was causing them to get locked out in the CAS server and we would simply inform the user that their account was getting locked out by a smart device using ActiveSync. 

I recently found in this article though that there is a way to figure out what the device exactly is causing the issue by looking at the IIS logs in the CAS Server. The article explains in detail what the log looks like, and what each field means. 

I'll try to provide a bit of a summary, but please visit the full article for more details. 

The logs can be found in the following locations:

• In Windows Server 2003: C:\WINDOWS\system32\LogFiles
• In Windows Server 2008: C:\inetpub\logs\LogFiles\W3SVC1
• In Windows Server 2012: I believe it should be the same but since we don't have a CAS server on a 2012 machine I wasn't able to confirm.

Here is the example provided, and I'll try to break it down as I understood it:

2012-01-10 14:42:26 172.32.22.12 POST /Microsoft-Server-ActiveSync/default.eas User=ratishnair&DeviceId=Appl8xxxxx4S&DeviceType=iPhone&Cmd=FolderSync&Log=PrxFrom:10.123.33.88_Error:BackingOffMailboxServer_ 443 CONTOSO\CAS01$ 10.123.33.88Apple-iPhone3C1/901.405 503 0 0 765

• 172.32.22.12 : The IP address of where the command was sent to.
• POST : The type of command that was issued on the Log.
• /Microsoft-Server-ACtiveSync/ : States that the type of command is ActiveSync.
• Default.eas : States the ActiveSync policy - this might vary depending on your settings.
• User= : The username who is running the command.
• DeviceID= : The ID that was assigned to the ActiveSync Device by the Exchange server when it was first setup. 
• DeviceType= : The Device Model - We've been using this to point the users to their device having issues.
• Apple-Iphone3C1/901.405 : The device's firmware version.
• 503 : This is the error code, which can be any of the ones found below:
• 200 – Authentication pass
• 400 – Bad/invalid request
• 401 and 403 – Unauthorized/server refusing request
• 404  – File not found
• 449 – Retry
• 500 – Server error
• 503 – Service unavailable
• 0 0 765 : I'm not 100% sure what this part means; however, the last 3 digits appear to change from log to log. I'm doing further research on this.

Well I hope this might help you troubleshoot this type of issues! I know it will help us a lot, and I am even thinking about allowing the Service Desk read access to this logs, though our Exchange admins aren't too fond of the idea, yet. 

Windows Server 2003 You did it again!

We recently had an outage on some of our VMWare hosts and after the outage was resolved and the hosts came back online we brought up all the VMs back online. Later that day one of my co-workers received a call regarding one of the VMs that was not able to be accessed.

After thoroughly troubleshooting the issue he asked me for some input.

He had done everything anyone would do to troubleshoot an issue with a VM Network:

• Made sure the IP address and subnet were correct.
• He double checked the VLAN on the VM host. 
• He deleted the virtual NIC and added a new one with a different driver

Unfortunately nothing was working. I took over the issue, and I was honestly at a stomp. After redoing everything he had done and a few other things I finally decided to check the Windows EventLog - I probably should have done that sooner. I found an event that said the following:

Event Type: Error
Event Source: IPSEC
Event Category: None
Event ID: 4292
Date:
Time: 
User: N/A
Computer: COMPUTER_NAME
Description:
The IPSec driver has entered Block mode. IPSec will discard all inbound and outbound TCP/IP network traffic that is not permitted by boot-time IPSec Policy exemptions.

After some researching I found the following VMWare article. It turns out this is actually not that an uncommon occurrence on VMs running Windows Server 2003. 

I followed the given instructions and I disabled the IPSec service - even though it wasn't even running - and rebooted the VM. When the system came back online so was the network. 

I hope this might help someone out there!