If the statement is true that you learn from your mistakes and failures, then I am getting really smart today!
I have successfully started using templates in VMware for a short while now. I thought I was getting pretty good at it since I was standing machines up very quickly and with little effort.
Today, however, I discovered a “glitch” with my process. When applying policy that would have the servers check the local WSUS server for updates I found that none of the servers where showing up in the administration console. I checked my policy(I have been known to make mistakes before), but everything was just as it should be. I clicked the refresh button with fingers crossed. A server showed up! I must just be too impatient, so I moved on to something more productive. A bit later I checked again, still only one server. HHMM, I started thinking about this, and all of the servers should have checked in by now. I set this policy up days ago. Ok, now for some more investigation.
I logged on to a server and in the run command window, I typed the following:
That should be enough to set things straight, or so I thought. However, nothing changed, and after 30 minutes, I determined there was something wrong. I also discovered that the server that was showing up in the WSUS admin console was changing. I again used my friends on the internet to get some answers. There were a lot of different suggestions and recommendations, but none of them really fit with my situation. Then I stumbled across this website: http://rialtus.livejournal.com/161268.html. This was the answer I was looking for. I exported the registry key that I would be removing, picked a server that didn’t have a good deal of importance at this time, and deleted the following registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\Windowsupdate\SusClientID
I rebooted the server and entered the following command in the run window wuauclt.exe /resetauthorization /detectnow
The server appeared in the WSUS administration console. Success! I repeated this process for all the other servers I created from the template and the results were the same. I had fixed the WSUS issue of my server not showing up in the console.
One of the first problems I noticed with Windows 8 is my drive mappings were missing. I joined a freshly installed Windows 8 workstation to the domain, and with that membership the workstation should be provided some drive mappings based on who I am when I log on to the computer. I am using Group Policy Preferences and security groups to map drives in this environment. It works exceptionally well on Windows 7 and Windows XP, but here I am looking at an empty explorer window that should have about 4 mapped drives sitting in it.
After some research, I discovered that this is actually a known issue, and not only is it a known issue, but according to message boards it has been known for quite some time now and nothing has been done to correct it. From the reading that I did, I determined that if you are a standard user (no administrative rights on the domain or on the local workstation) you will be provided your network drives. However, if you are an administrator (domain or local), the group policy applies successfully and no errors result, but no drives are displayed in the explorer window. That seems really backwards to me as a network administrator, but that is what is occurring.
According to posts that I have read on the subject, it would seem that because group policy preferences are applied using the users security context, and the explorer window by default is launched without any administrative privileges, it doesn’t have the rights to display the drives. I don’t know if I believe that, but the users who were stating that, also provided the workarounds that gave me my drives back.
So, because no one seems to be able to pin-point the exact issue and several changes have provided a workaround, I am just going to list all the possibilities here and they can be attempted at will.
“uncheck” the reconnect option in the drive mapping settings.
run in logged-on user’s security context (user policy option)
It was also suggested that removing Item-level targeting would map the drives, but I don’t think that is something that most people will want to do since Item-level targeting is one of the key features with Group Policy Preferences.
I was presented with a troubleshooting issue today that involved PowerShell and Exchange. The user wanted to get statistics for the mailboxes in the Exchange environment. The problem actually ended up being 2 different changes.
First, the PowerShell command had some invalid syntax in it. Below is the full command.
The problem with this syntax is found in the Get-MailboxStatistics section. The parameter “-Server [EXCHANGESERVERNAME]” was causing every mailbox to return an error. When this part of the command is removed, the command executes successfully, however, the following is displayed on the screen.
This warning was a result of a mailbox that was not accessible. In this case the mailbox name was SMEX_PPMKEEX2_MB. When reviewing the mailbox, it was discovered that the mailbox didn’t appear to have all the required attributes. Further confusion ensued when the required attributes were not able to be added. After a long discussion with the client, it was determined that this mailbox was not in use and was no longer required. I disabled the mailbox (recovery is still possible during the retention policy time frame this way) and ran the script again. This time everything came back clean with the only warnings being that a handful of mailboxes had never been accessed since part of the command was looking at Last Logon Times.
Another important thing to note with this engagement was what the Storage Limit Status response for each mailbox really indicates. If NoChecking is returned the mailbox does not have a size limit restriction set on it. If BelowLimit is returned, this means that the mailbox has a limit set on it, but it has not been reached yet. It is important to remember that mailbox size limits can be set on an entire mailbox database, or individual mailboxes. Strange results might be returned when querying the mailbox properties if the wrong syntax is used. Typing one thing will return no limit while typing another query will return the size limit restrictions.
Mobility has really caught on recently and everybody wants in. This can be using that new smart phone to check your email to working from home. This is great technology it has unchained us from “the office”, but it can have it’s frustrations as well. For example, how do end-users that don’t frequently make it to the office change their password when the time comes?
This was asked of me recently. Now of course I am aware that you can change your password using OWA after a successful logon, but that doesn’t help if you need to update your password before logging on. A client wanted to create accounts and using OWA change the password on first logon so that the end-user was not required to travel to the office to perform this task. At first I didn’t think it was possible, but after some digging around, I ran into this site that actually provided documentation on allowing just that.
As I read through the article I realized that to enable this functionality it takes only a single registry key change. Below is the excerpt from the site that provides the details of how to accomplish this.
To enable this feature you will need to modify the registry on the Exchange server which runs the CAS role and reset IIS.
NOTE: You need to make the registry modification on all CAS servers, if you have more than one in your environment.
I put this process together for securing ActiveSync traffic to IIS when using a MobileIron Sentry. When managing mobile devices it is important not to leave “back doors” in your configuration. If ActiveSync traffic is allowed from anywhere, an end-user could easily configure the connection directly to the Exchange CAS on the mobile device bypassing the Sentry security appliance. To prevent this, but still allow OWA(Outlook Web Access) communication, the following should be applied to all CAS servers in the environment.
This process can be applied generically for many different applications, Securing ActiveSync communication to run through a MobileIron Sentry is only an example. This process is leveraged to block traffic from an Exchange CAS for ActiveSync traffic only while still allowing Outlook Web Access traffic. If all traffic on port 443 is unnecessary, using a simple rule on the firewall would be a better way to accomplish this.
To begin, open the IIS Management MMC from the start menu This may be found on the recent applications list, or it is also under “Administrative Tools”.
Once the Management Console is open, drill down the tree on the left side of the console by expanding the ”[servername]”, then “Sites”, then “Default Web Site”. Locate the “Microsoft-Server-ActiveSync” virtual directory and highlight it.
On the middle pane, under IIS, locate the listing / icon for “IP Address and Domain Restrictions”. This is the option used to set ACLs based on IP address or domain name.
Double clicking the icon will open the settings pane. On the “Actions” pane on the right side of the console, select the link titled “Add Allow Entry….”.
This will open a dialog box that will allow the input of the IP address or range of addresses that should be allowed. Enter the Sentry address(es) to the window and click “OK”.
This hasn’t really changed anything yet as traffic is allowed from everywhere currently. However the next step is to prevent the traffic from everywhere else. By default traffic is allowed from everywhere. To change this, click the link “Edit Feature Settings….” In the right pane.
Again, a dialog window will open. Changing the “Access for unspecified clients:” drop down to “Deny” will prevent any access to this virtual site except what is listed in the middle pane, in our case the sentry server(s). Click OK on the dialog window.
The final step is to perform a restart of the IIS server. This can be done by opening a command prompt and issuing the command “iisreset”. To open a command prompt, click start then select “Run …” from the list. When the “Run …” dialog window appears, type “cmd” in the box and press “Enter”. You will see a “DOS” like window. Type “iisreset” and press “Enter”.
Once the services have restarted, the ActiveSync server will not be accessible from any location other than the specified IP addresses.
Using Group Policy to enable WMI (Windows Management Instrumentation) remote requests through the Windows Firewall
It is always a good idea to enable the Windows firewall under the domain profile. Enabling the firewall can prevent needed functionality as well. For example, in some scenarios it may be required to be able to interact with client workstations or servers via WMI (which would be a type of unsolicited DCOM request on port 135). Windows firewall will block this functionality unless you explicitly allow it. To allow WMI remote requests through the windows firewall using Group Policy, the “Allow Remote Administration Exception” policy needs to be enabled in the group policy object being applied to the workstations and / or servers requiring this access in the environment. In order to set this, open up Group Policy Manager, and browse to the following location: Computer Configuration\Administrative Template\Network\Network Connections\Windows Firewall\Domain Profile(if setting this for the domain profile). The same policy can be found in the “Standard Profile” as well.
Once you enable “Allow Remote Administration Exception” (and the computer objects refresh their policies usually 4 hours), WMI traffic should be allowed.
If you are impatient like me, sometimes it is best to just issue a command from the commmand line and be done. The following are examples of commands that can be used to enable the same functionality as above.
Allow WMI through the Windows Firewall from the command line
If a connect attempt using wbemtest.exe fails – follow these steps to allow the requests through the firewall.
From the local machine command line, if the platform is Windows XP / Server 2003 (Below are three commands each providing different options)
c:\> netsh firewall set service remoteadmin enable
c:\> netsh firewall set service remoteadmin enable subnet
c:\> netsh firewall set service remoteadmin enable custom 192.168.1.1,LocalSubnet
Windows7 / Server 2008 (Two commands below provide 2 ways to set the firewall to allow WMI)
c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
You should see something like the following if successful.
Updated X rule(s) (where X is the number of rules updated)
c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes
Again, you will see something like the following if successful.
Updated X rule(s).
This should be all that is required to allow WMI remote requests through the Windows Firewall. The name of the Group Policy Object setting prevented me from getting this to work for quite a while.
The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied. WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly. Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure. While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator. With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually. So WMI filtering can reduce management overhead and prevent errors in policy application.
A couple of things to note when designing Group Policy using WMI filters:
The WMI query syntax is similar to an SQL query
Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
The more filters are used and the more complex the queries, the greater the length of the logon time
Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled. Every configuration that is processed will add time to the logon process even if it is not being used
By default no WMI filters exist in Active Directory. The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.
To create a new filter, right click the WMI Filters container and select “new” from the list.
This will open the WMI filter dialog window. (shown below)
Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)
This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed). It should be defaulted to root\CIMv2. It will also have a big box to type the query you want to run in. This is where you put the following:
select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"
When you click “OK” on the WMI dialog window you will see the following:
Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery. Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times. Click the “Save” button to save your new filter.
If everything worked out, you will now see something similar to the following:
Where a new filter will be listed under the WMI Filters container. The last step before testing is associating the filter with the GPO. To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window. Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).
There really isn’t too much that can go wrong with these. A couple of things that should be verified are the following:
Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
Make sure that the group policy is applied to the correct OU and that it is enabled
Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
Run the following command from a command prompt to verify that the GPO is applied as expected
This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.
In order to active a server via KMS, the following steps must be completed.
First log on to the server and verify that Windows has not been activated. This can be determined by looking at the activation status show below.
Once it has been determined that Windows needs to be activated, use the following steps to active using the KMS server.
First the key to be used to active Windows must be set. It should be assumed that either no key has been entered, or an invalid key was entered and needs to be updated. If a valid KMS key was used for activation, activation should be automatic.
From the start menu, either search for command prompt or locate it on the start menu and right click it and select the “Run as administrator” option. This will cause the command window to be run with elevated privileges and is necessary to run the commands needed to activate Windows.
Once the Command Prompt window is open, enter the following at the prompt.
slmgr /ipk YC6KT-GKW9T-YTKYR-T4X34-R7VHC
This will set the Windows activation key. NOTE: A Windows KMS key must be used as retail keys will fail to activate against a KMS server.
If the command completes successfully, a window will popup displaying the message “Installed Product Key xxxxx-xxxxx-xxxxx-xxxxx-xxxxx successfully.”, where “xxxxx” is the key entered.
Now that the correct key has been set, all that is left to do is activate Windows. Using the same Command Prompt window, type the following command. This will submit the request to active Windows.
If this is successful, another popup window will be displayed showing the status of the activation as shown below.
Finally to verify that everything is fully activated, going back to the original window should provide the updated status of the product showing activated.
That is the process for activating via KMS server.
To determine the status of the KMS server, the following command can be run in the same command prompt window using the same slmgr.vbs script, but using the following switches:
This will provide the details of the KMS server including things like number of activations, etc., as shown below.
If you experience any issues, please see the troubleshooting section below for setting up a KMS server.
KMS activation can only fail for a handful of reasons. A couple of things to check:
DNS entries for the KMS server
The KMS key, a specific key is required for KMS activation (see KMS server key used on workstations below)
Potentially the Activation key used needs to be “reset”
The KMS server has not been properly configured
The KMS server has not been fully activated. This one is strange. The KMS server will not start accepting activations until a specific number of attempts have been tried
KMS server key used on workstations
Recently, I had the opportunity to work on a KMS environment where the wrong key was used, but the wrong key was used on the clients. All the clients were built from an image where the KMS server key was used. When the workstations were deployed into the environment, they all wanted to be KMS servers and advertized themselves via DNS as KMS servers. This caused some pretty significant chaos as you can imagine. In order to clean this up, the keys were manually changed on all the workstations, and the DNS entries that had been created were removed. We were not able to determine a better / automated way to update the keys on the workstations. It was a time consuming lesson.
Updating / Moving the KMS server
If an existing KMS server is already configured and it needs to be retired or removed, the steps are a little more complicated. It would be nice if the key could just be changed. The problem comes in when DNS records are involved and without completely removing the KMS key, the server still wants to publish itself as a KMS server. The following link provides a step by step process for removing the old server as a KMS server and resetting the KMS key.
I have been using Windows 8 for some time now trying to get familiar with the new interface. So far, it has been “rocky” at best. For Windows 8 it is a love / hate relationship with me. There are things that I really like about it, but things that can be incredibly frustrating also. Here are a couple of tips that I have picked up to help with the Start Screen that may help the transition if you decide to take the route to Windows 8.
The “Windows” key
By itself, it brings up the start screen
First and most important is the “Windows” key. This key by itself will access the start screen and when used in conjunction with other keys can provide several other functions. If not currently a hot key user, before going to Windows 8 it is time to learn. Without the ability to use touch leaving the only other options of mouse and keyboard for interaction, hot keys will become invaluable when navigating the system.
Typing while in the “Start Screen”
Automatic searching and providing results of applications, files, etc. on the computer that can then be clicked to execute.
Before finding this functionality, Windows 8 seemed extremely “clunky”, and using and or finding applications felt like a task that just took too long. To be honest, I stumbled on it by accident, but have been using it ever since. After clicking the “Windows” key, just start typing the name of the item you are looking for and the windows start menu will automatically locate it for you.
The “Charms” menu can be accessed by typing the “Windows” key and C at the same time.
The “Charms” menu is not a personal favorite, but it is what Microsoft deemed as important and the new direction. The shortcut is the “Windows” key and the C key and it provides a launch pad of sorts to access many different areas of the OS. Before learning the shortcut keys, this was the primary way I navigated the system. It has many of the same functions of the Start screen like search, the start menu screen itself, but includes things like sharing, devices, and settings.
Power User Menu
“Windows” X key creates a menu in the lower left corner of the screen and provides commonly used administrative tasks.
This shortcut provides a quick list of administrative tasks. While everyone may not find this menu beneficial, it contains a list of items that can make administration a little more efficient. The screenshot below provides all the options that are presented in the menu.
Logging out / Shutting down
Shutdown: Found on the “Charms” menu
Log out: Found on the Start screen under the current user menu
The decision to put the shutdown and log off options in completely different menus is probably one of the least understood from a functionality standpoint, but more than likely was implemented for the touch functionality. The shutdown menu is located under the “Settings” option in the “Charms” menu, and the Log off option is located under the User menu on the Start screen. Examples of both of these are shown below.
and the user menu found on the start screen
This user menu is found on the top right part of the screen. These are the shortcuts and functionality that I have discovered currently and have found important or useful.
The goal of this article is to provide clear, concise method for running PowerShell scripts using Windows task scheduler. Running a PowerShell script using the task scheduler may not be as straight forward as one might expect. In fact, it is quite different from running standard shell scripts. This article should provide the generic syntax for running PowerShell scripts via task scheduler as well as some basic troubleshooting when things go wrong.
PowerShell is Microsoft’s new scripting language that allows administrators to perform almost any task. It is becoming more and more a requirement of the professional administrator. Getting simple things to play nice still seems to be a small issue.
The following links were used in creating this article.
In order for a scheduled task to be successful when running a PowerShell script, the location / path of the script cannot simply be provided. The executable of PowerShell needs to be the program to run, with the path to the script to be run submitted as the arguments. Occasionally, it might be required to provide the full path for the PowerShell executable, but usually simply supplying PowerShell.exe should do the trick. The following is the syntax that can be used if supplying the whole command on the program line. Task scheduler will normally recognize this and ask if you want to place the arguments in the arguments section. This will accomplish the same thing as manually separating the command before entering it.
At times, using the following parameter is required to allow an unsigned script to run correctly.
This parameter tells PowerShell not to look at the script to validate it, but simply to run it.
The following are common issues preventing a PowerShell script from running successfully.
Does the script require the “-executionpolicy bypass” parameter to bypass the signing checks?This is probably the most sneeky of the bunch. It may appear that everything is running successfully, but nothing actually ever happens.
Does the script require elevated privlages to run successfully?Some PowerShell scripts will only run with elevated privileges. Verify that the check box on the first page of the schedule task configuration windows is checked for “run with highest privileges”.
Is the syntax correct for executing the script?The easiest way to verify you have the correct syntax is to run it from the run dialog. If the script fails here, the problem is not with the scheduled task, but with the syntax of the command itself.