Paul from today’s 5050 Exchange 2007 class was looking for some more information on how SCR works and ways to set it up.. Here ya go Paul!
Video series on SCR – You Had me at EHLO blog
How SCR works within Exchange 2007 SP1 – You had me at EHLO blog
Archive for April, 2010
If you have followed me on Twitter (@csolarz) then you may have heard how I’ve experienced some issues after installing the RTM bits of Office 2010.
First let’s cover the installation experience. I have Windows 7 Ultimate 64-bit on my laptop with 4gb of ram. I normally do NOT use very large files on this system. Thus the 64-bit Office beta I was running really was completely unnecessary. I decided for the sake of plug in compatibility I would run 32-bit office 2010 now that it’s RTM and available. I went and installed it. I had some odd issues with PowerPoint 2010 back in beta and had hoped they wouldn’t crop back up. To my dismay they did. All of the 2010 32-bit apps would run perfectly,…. except PowerPoint. Well as an instructor guess which one I use the most? Yup… PowerPoint. Feeling lost and helpless I did some testing.
PowerPoint in safe mode didn’t do any good. I knew there were some plugins that PowerPoint would be using, but how could i disable them without the app actually running?
I turned to my friends on the TechNet forums. There i posed my conundrum to the masses and Aaron from Microsoft led me to the promised land. He gave me some registry paths to check to see which plug ins were loaded. I then noted WebEx addins there. I hardly use it on my laptop so I just deleted them. Once this was done BAM, PowerPoint was resurrected!
One other odd thing I noted that Outlook 2010 was no longer showing my messages in “Conversation View” So to turn this back on i just had to access the “View” tab and turn it back on via a check box…
Taken from Gray Knowlton’s blog.. Gray matter
Office 2010 Application Compatibility: Deep dive on the Code Compatibility Inspector
Continuing with the deep dive into new tools in Office 2010 Application Compatibility, we would like to explore and illustrate in detail how Code Compatibility Inspector (CI) functions.
The Microsoft Office 2010 Code Compatibility Inspector is designed to assist an enterprise or small business with updating VBA and VSTO code so that it becomes compatible with Office 2010. While the tool does not directly make code corrections (other than correcting Declare Statements for 64bit compatibility in VBA), it does comment code in locations where potential Object Model changes have been identified. Users or developers debugging their code can get assistance from the comments and links to topics on MSDN that detail the changes that may be affecting a specific line of code. Here is what CI actually do:
- The Code Compatibility Inspector consists of four addins that load in PowerPoint 2010, Word 2010, Excel 2010 and Visual Studio (VS 2008 is the targeted version with VB.NET and C# languages supported).
- It operates on a per-user/per-document/per-solution basis. When a user opens a document (or Visual Studio solution) they can run the tool from the developer tab (or Tools menu in Visual Studio).
- The CI scans the VBA projects in the current document or Visual Studio Solution via simple text search looking for parentObject.Property combinations.
- It also scans Declare statements for 64bit compatibility in VBA.
- Where potential issues are found, the tool will add comments right next to that code, including links to the topics on the details of the change pointing to MSDN.
- When completed, the tool will provide a summary and detailed report of what was found in the project as well as an option to remove the inserted comments.
CI can be run by an individual developer or macro user, when they have access to the code. Here is what you can expect to see when you download and run the installation package:
You have choice of the installation either in the Office VBA environment or in the Visual Studio environment or both if you prefer.
To inspect a code in a document for compatibility, you would follow these steps:
- Open the desired document in PowerPoint/Word/Excel.
-
On the Developer Tab, click Inspect VBA Code.
- On the Inspect VBA Project dialog, select the options you want, then click Inspect.
- The Inspect Visual Basic for Application Projects has to be checked in order to inspect your VBA project for potential Object Model changes.
-
The Inspect Declare Statements will make your project 64bit compatible. Select this option if:
- Your project will only be run on Office 2010.
- May be run on a system running 64bit Office 2010.
- The Add comments option will place comments in your code where potential compatibility issues are discovered. These comments will appear similar to the following:
The <URL></URL> tag will contain a URL to the relevant site on MSDN describing the suspect OM change found (it is not in this picture because.
-
The Detailed Report option will create a text file report at the end of the inspection process. This report will contain the following information:
SUMMARY:
========
Document scanned: c:Test.ppt
Date scanned: Tuesday, October 20, 2009
Total lines scanned: 319
Total items found: 35
Deprecated items: 0
Changed items: 2
Redesigned items: 0
Declare statements: 32DETAILS:
========
MODULE: clsPPTEvents
FUNCTION: PowerPointApp_WindowSelectionChange
LINE: 20
TYPE: CHANGE
ITEM: Presentation.SlideMaster
URL:
CODE: Set objMaster = ActivePresentation.SlideMaster
MODULE: clsPPTEvents
FUNCTION: PowerPointApp_WindowSelectionChange
LINE: 37
TYPE: CHANGE
ITEM: Presentation.TitleMaster
URL:
CODE: Set objMaster = ActivePresentation.TitleMaster
- When the scan is completed, you will get a summary report similar to the following that will detail the number of changed items, deprecated items and design changed items (described in more detail below):
- Total Lines Scanned – the total number of VBA code lines scanned in the document.
- Total items found – this is the total number of declare statements updates, changed items, deprecated item and design change items found in the code.
- Deprecated items – these are items that were found which were removed from the object model. These items may require a code workaround – an alternative approach as the feature it is dependent on is no longer available in the product.
- Changed items – these are the items found where the syntax of the command were changed and may need to be updated.
- Redesigned items – these are items where the syntax is still the same and the item/feature still exists. However, the desired result may no longer be the same. For example, a textbox formatting may have changed because of new text services. While a textbox will be created, the layout of the text in the box may differ when compared to previous versions.
- Declare statements – this is the count of the total number of Windows API statements that were detected in the VBA code and were updated for 64-bit compatibility by adding the PTRSAFE keyword.
Once you have successfully inspected your code if CHANGED, DEPRECATED or REDESIGNED items were found will be to start debugging your code. We suggest you perform a full test pass on your code, inspecting each function. If problem are found and you break into the debug of your code, check to see if there is a VSTO Code Compatibility Inspector comment above that line. If there is, it should give you direction on the type of problem occurring in that line of code and will contain a URL that you can copy and paste into your browser to get more information. Once you have completed verifying your code for Office 2010 compatibility, you can remove the comments from the code by clicking the Remove VSTO Inspector Comments on the Tools menu:
As we mentioned in our previous post on OEAT – we will be offering a preview of the tools for Office 2010 application compatibility in early December. We also recommend you stay tuned to the Office 2010 public beta to be delivered in November as well, so that you can experiment with getting your 2003 and 2007 solutions to work with Office 2010.
I just got hooked up with this tool and will be blogging more on this as I work out it’s in ‘s and out’s… This really appears to be a great fit for SMB’s or a place with an over tasked IT management group ( isn’t this the case in EVERY IT dept?) but to start..
What is it?
Windows Intune is a new offering from Microsoft that includes the Windows Client Software Assurance, the Microsoft Desktop Optimization Pack, and, last but not least, the online desktop management service called Windows Intune. You can sign up for a beta account of the Desktop Management component through the Microsoft Online Services Customer Portal. This beta contains all the features that are planned for release, and will allow you to deploy to as many as 20 PCs.
What does Windows Intune do?
Windows Intune is an online service that allows you to protect update and manage your PCs from the cloud. When you sign up for an account, you will be able to:
ü Protect PCs from malware
ü Manage updates
ü Proactively monitor PCs
ü Provide remote assistance
ü Inventory hardware and software
ü Set security policies
As with any beta release, our goal here is to have real customers give the service a solid evaluation, provide feedback and comments, and of course file bugs you may find along the way. To help you do this, we have established a TechCenter site that includes all the resources you will require, such as deployment information, discussion forums, support, and how-to tips and tricks to get you going.
How to enroll:
The Windows Intune beta is publicly available, but space is limited! We will be accepting the first 1000 customers who sign up through the Microsoft Online Services Customer Portal. Once you’re signed up and you have received the confirmation email, you can log in to the service, download your client software and deploy it to as many as 20 computers. When you start using the service, we encourage you to visit our TechCenter site, where you can post questions in this forum, review documentation and get assistance.
Make sure you are using the Intune technet forums if you are a beta tester! also Intune related items will be search able on the KB library!
Good ol’ technet!
Active Directory module cmdlets
You can use the Active Directory module cmdlets to perform various administrative, configuration, and diagnostic tasks in your AD DS and AD LDS environments. In this release of Windows Server 2008 R2, you can use the Active Directory module to manage existing Active Directory user and computer accounts, groups, organizational units (OUs), domains and forests, domain controllers, and password policies, or you can create new ones.
The following table lists all the cmdlets that are available in this release of the Active Directory module in Windows Server 2008 R2.
Cmdlet
Description
Adds one or more service accounts to an Active Directory computer.
Add-ADDomainControllerPasswordReplicationPolicy
Adds users, computers, and groups to the Allowed List or the Denied List of the read-only domain controller (RODC) Password Replication Policy (PRP).
Add-ADFineGrainedPasswordPolicySubject
Applies a fine-grained password policy to one more users and groups.
Adds one or more members to an Active Directory group.
Add-ADPrincipalGroupMembership
Adds a member to one or more Active Directory groups.
Clears the expiration date for an Active Directory account.
Disables an Active Directory account.
Disables an Active Directory optional feature.
Enables an Active Directory account.
Enables an Active Directory optional feature.
Get-ADAccountAuthorizationGroup
Gets the Active Directory security groups that contain an account.
Get-ADAccountResultantPasswordReplicationPolicy
Gets the resultant password replication policy for an Active Directory account.
Gets one or more Active Directory computers.
Gets the service accounts that are hosted by an Active Directory computer.
Get-ADDefaultDomainPasswordPolicy
Gets the default password policy for an Active Directory domain.
Gets an Active Directory domain.
Gets one or more Active Directory domain controllers, based on discoverable services criteria, search parameters, or by providing a domain controller identifier, such as the NetBIOS name.
Get-ADDomainControllerPasswordReplicationPolicy
Gets the members of the Allowed List or the Denied List of the RODC PRP.
Get-ADDomainControllerPasswordReplicationPolicyUsage
Gets the resultant password policy of the specified ADAccount on the specified RODC.
Get-ADFineGrainedPasswordPolicy
Gets one or more Active Directory fine-grained password policies.
Get-ADFineGrainedPasswordPolicySubject
Gets the users and groups to which a fine-grained password policy is applied.
Gets an Active Directory forest.
Gets one or more Active Directory groups.
Gets the members of an Active Directory group.
Gets one or more Active Directory objects.
Gets one or more Active Directory optional features.
Gets one or more Active Directory OUs.
Get-ADPrincipalGroupMembership
Gets the Active Directory groups that have a specified user, computer, or group.
Gets the root of a domain controller information tree.
Gets one or more Active Directory service accounts.
Gets one or more Active Directory users.
Get-ADUserResultantPasswordPolicy
Gets the resultant password policy for a user.
Installs an Active Directory service account on a computer.
Moves a domain controller in AD DS to a new site.
Move-ADDirectoryServerOperationMasterRole
Moves operation master (also known as flexible single master operations or FSMO) roles to an Active Directory domain controller.
Moves an Active Directory object or a container of objects to a different container or domain.
Creates a new Active Directory computer.
New-ADFineGrainedPasswordPolicy
Creates a new Active Directory fine-grained password policy.
Creates an Active Directory group.
Creates an Active Directory object.
Creates a new Active Directory OU.
Creates a new Active Directory service account.
Creates a new Active Directory user.
Removes an Active Directory computer.
Remove-ADComputerServiceAccount
Removes one or more service accounts from a computer.
Remove-ADDomainControllerPasswordReplicationPolicy
Removes users, computers, and groups from the Allowed List or the Denied List of the RODC PRP.
Remove-ADFineGrainedPasswordPolicy
Removes an Active Directory fine-grained password policy.
Remove-ADFineGrainedPasswordPolicySubject
Removes one or more users from a fine-grained password policy.
Removes an Active Directory group.
Removes one or more members from an Active Directory group.
Removes an Active Directory object.
Removes an Active Directory OU.
Remove-ADPrincipalGroupMembership
Removes a member from one or more Active Directory groups.
Removes an Active Directory service account.
Removes an Active Directory user.
Changes the name of an Active Directory object.
Reset-ADServiceAccountPassword
Resets the service account password for a computer.
Restores an Active Directory object.
Gets Active Directory user, computer, and service accounts.
Modifies user account control (UAC) values for an Active Directory account.
Sets the expiration date for an Active Directory account.
Modifies the password of an Active Directory account.
Modifies an Active Directory computer.
Set-ADDefaultDomainPasswordPolicy
Modifies the default password policy for an Active Directory domain.
Modifies an Active Directory domain.
Sets the domain functional level for an Active Directory domain.
Set-ADFineGrainedPasswordPolicy
Modifies an Active Directory fine-grained password policy.
Modifies an Active Directory forest.
Sets the forest mode for an Active Directory forest.
Modifies an Active Directory group.
Modifies an Active Directory object.
Modifies an Active Directory OU.
Modifies an Active Directory service account.
Modifies an Active Directory user.
Uninstalls an Active Directory service account from a computer.
Unlocks an Active Directory account.
.gif)
Note
To list all the cmdlets that are available in the Active Directory module, use the Get-Command *-AD* cmdlet.
For more information about—or for the syntax for—any of the Active Directory module cmdlets, use the Get-Help <cmdlet name> cmdlet, where <cmdlet name> is the name of the cmdlet that you want to research. For more detailed information, you can run any of the following cmdlets:
- Get-Help <cmdlet name> -Detailed
- Get-Help <cmdlet name> -Full
- Get-Help <cmdlet name> -Detailed
- Get-Help <cmdlet name> -Examples
Our friends over at the Scripting Guy Blog have an incredible write up on PowerShell 2.0 remoting which contains excerpts from the book Windows PowerShell 2.0 Best Practices by Ed Wilson
Hey, Scripting Guy! I have heard that remoting is one of the cool new features of Windows PowerShell 2.0. What are the remoting features in Windows PowerShell 2.0, and how should I use them?
– FL
Hello FL,
Microsoft Scripting Guy Ed Wilson here. I spent yesterday evening crawling around in my attic re-doing my telephone lines. I wanted to move my ADSL router to the other side of my office, and there was not a telephone line there. In addition, I wanted to add a couple of new Ethernet ports to my premises wiring to get ready for my new computer that will be arriving in a few days. It reminded me of when I was just starting out as a computer dude, way back before VBScript was even invented. It was kind of cool getting out my fox and hound, my multimeter, my punch-down tools, and clogging my lungs with insulation. Something bordering on the nostalgic I imagine. The bad thing about doing those sorts of installation jobs at home is that you have to clean up after yourself a little better than you might if you were at work, especially at my house because the Scripting Wife does not cut any slack.
Speaking of nostalgic, I remember back in the day when if you wanted to run a command on a remote computer, you either had to get up out of your chair and go to the computer and type in the command, or get someone on the phone who could type the command for you. There was no centralized management and not much in the way of remote access either. Ah, the good old days! Like 300 baud modems and spending all day to download a single file—no, thank you. Sometimes good old days are best left in the past. I prefer to live in the present, or even the near future. With the release of Windows 7 and Windows PowerShell 2.0, the near future has arrived!
Remote PowerShell Session
When you have a series of commands you need to enter, or you have some work you need to accomplish on a remote server or workstation, a remote interactive session is the remote tool you will need to use. A remote interactive session turns the Windows PowerShell session on your machine into a Windows PowerShell session on a remote machine. All commands you type are executed as if they were typed on the console of the remote computer.
Be careful with path commands in a remote interactive session—they resolve to the remote computer. This can be very confusing at first.
You are allowed to have only one remote interactive session running from your Windows PowerShell console. It is permissible, however, to have multiple Windows PowerShell consoles open, and for each to have a remote interactive session running. To begin an interactive Windows PowerShell session, you use the Enter-PSSession cmdlet. You do not need to rely upon pass-through authentication because the cmdlet supports the parameter. This syntax is illustrated here:
Enter-PSSession -ComputerName Berlin -Credential nwtraders/administrator
To create a remote Windows PowerShell session, you use the New-PsSession cmdlet. The use of New-PsSession and Enter-PsSession are illustrated here.
PS C:> New-PSSession -Name server1Test -ComputerName server1
Id Name ComputerName State ConfigurationName Availability
– —- ———— —– —————– ————
4 server1Test server1 Opened Microsoft.PowerShell Available
PS C:> Enter-PSSession -Name server1Test
[server1]: PS C:Usersadministrator.NWTRADERSDocuments> hostname
Server1
[server1]: PS C:Usersadministrator.NWTRADERSDocuments> gwmi win32_operatingsystem
SystemDirectory : C:Windowssystem32
Organization :
BuildNumber : 7600
RegisteredUser : Windows User
SerialNumber : 00486-001-0001076-84399
Version : 6.1.7600
[server1]: PS C:Usersadministrator.NWTRADERSDocuments> exit
PS C:> gwmi win32_operatingsystem
SystemDirectory : C:Windowssystem32
Organization :
BuildNumber : 7600
RegisteredUser : win7
SerialNumber : 00392-918-5000002-85015
Version : 6.1.7600
PS C:>
Remote command execution
If you only have a couple of commands you wish to execute on the remote computer, you can use the Invoke-Command cmdlet. When using the Invoke-Command cmdlet, a remote connection is established on the remote computer, the command executed, data returned to the originating computer, and the connection broken. A subsequent command to the remote computer would create a new temporary connection in the same manner as the first. There is no persistent connection, data, or shared state between the connections. In the code below, we execute the Get-Host cmdlet on a remote server named berlin. You will see that the results from berlin are returned to the host computer:
PS C:> Invoke-Command -ComputerName berlin -ScriptBlock { get-host }
Name : ServerRemoteHost
Version : 1.0.0.0
InstanceId : 4bef95fc-7ee4-4be6-93b8-be7ea9ed3757
UI : System.Management.Automation.Internal.Host.InternalHostUserInterf
ace
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData :
PSComputerName : berlin
Persistent connection
If you wish to run a series of commands on multiple computers and maintain the ability to share data between the commands, you will need to first make a persistent connection prior to using the Invoke-Command cmdlet. To create the persistent session, use the New-PsSession cmdlet and specify the name of the computer. You will need to save the returned connection object in a variable. You then use this connection when running the remote command. In the example here, we first establish a persistent session with a computer named berlin. We store the returned session object in a variable named $session. Next we use the session parameter when using the Invoke-Command cmdlet to run two commands. The first command uses the Get-Command cmdlet to get a collection of commands from the remote computer. It stores those command objects into a variable named $a. In the next command, we continue to use the persistent connection, and this time we share the $a variable between the running of the two commands. We pass the objects contained in the $a variable to the Get-Help cmdlet. This code is seen here:
$session = New-PSSession -ComputerName berlin
Invoke-Command -Session $session -ScriptBlock { $a = Get-Command }
Invoke-Command -Session $session -ScriptBlock { $a | get-help }
As seen in the following image, you cannot use the session name that was created earlier in our example. This is because the session name is a string, and the –session parameter wants to receive a session object. If you attempt to use the session name from an earlier command, you will receive an error that states that Windows PowerShell cannot bind the –session parameter to a string. After a new session object is created, the Invoke-Command cmdlet can be used to run a command on a remote computer. This is seen here:
Remote script execution
If you have a script you need to execute on a remote computer, but the script is stored locally on your host machine, in the past you would have had to physically copy the script to the remote computer, and then use something like the create method from Win32_Process to execute remote computer. In Windows PowerShell 2.0, we can use the Invoke-Command cmdlet to execute a script that is stored locally and have it run on a remote computer. When the script is run, the results of the script are returned to the local computer. In the example shown here, we use the Invoke-Command cmdlet to run a script called getBios.ps1 on a remote computer named berlin. The filepath parameter is used to tell the Invoke-Command cmdlet where to find the script. This path must resolve locally.
PS C:> Invoke-Command -ComputerName berlin -FilePath C:fsogetBios.ps1
SMBIOSBIOSVersion : 080002
Manufacturer : American Megatrends Inc.
Name : BIOS Date: 02/22/06 20:54:49 Ver: 08.00.02
SerialNumber : 2096-1160-0447-0846-3027-2471-99
Version : A M I – 2000622
PSComputerName : berlin
As a best practice, use a remote interactive session when you wish to perform multiple commands on a single remote computer. If you have one or two commands that you wish to run on multiple remote computers, use remote command execution. If you have multiple commands you wish to execute on multiple computers, use a persistent connection. If you need to run a script that does not exist on a remote computer, use remote script execution.
Well, FL, that is about it for a quick overview of remoting in Windows PowerShell. Join us tomorrow when we dive into our virtual mail bag and respond to a bunch of questions requiring relatively short answers. It is time for Quick-Hits Friday.
If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, keep on scripting!
It took some serious searching for some silly reason but here is the dealio. Head over to THIS MS support document for links and steps to get PS v 2.0 installed and running on your XP and higher boxes.
I ran across some great info today on just that – see below!
Managing VMware with PowerShell FAQ
- Good intro book: free Windows PowerShell workshop book
- More advanced stuff: Windows PowerShell v1.0: TFM, 2nd Edition
- Very advanced: Windows PowerShell in Action
our friends at @MicorsoftPress (follow them on twitter! or catch up with them on Facebook) have been putting out some seriously high quality product of late. I attribute this mostly to their choice of topic seeing the communities needs and their choice of top notch writers! (looking at you Ed Wilson!) below are my thoughts / experiences on a few of the books I’ve read from the MSPress stable..
First off, the Windows PowerShell™ Scripting Guide is written by my newest hero Ed Wilson. This book is a great launching point for most administrators faced with the proposition to have to learn PowerShell in general or for a specific task. If you know a thing about me, I am an infrastructure guy through and through. The sheer thought of having to learn a “language” for programming or otherwise sends chills down my spine. I tried to tackle VB6 back in the day and it almost drove me to the looney bin. I have found you really need a certain mentality to be a “Code Guy”, and that is not in any fiber of my soul. So personally being faced with this I knew I had a serious challenge ahead of me. Now I had a general idea of what PowerShell did and was from my experiences with Exchange Server 2007. Now that exposure was very focused on the mail side and didn’t really give me a chance to see it’s true power and level of reach for PowerShell.
He starts quickly and doesn’t bore you with a lot of the extraneous details and gets on topic fast, making things relevant to your job! Ed quickly makes you familiar of the core components and makes you feel comfortable with them. Once your PowerShell training wheels are off, let’s get working on things you can USE TODAY! As a trainer I recommend this and a few other of his books to all of my students since I have personally found them invaluable. Not only good as a learning tool – but a great on going reference and key component of any tech library. If you are still looking for something at a low level, his other book Microsoft® Windows PowerShell™ Step By Step is also a pick to click!
Our next title is the Windows PowerShell™ 2.0 Best Practices again by Ed Wilson. This book really builds on all we’ve learned from Ed in the first book(s). As great as it was to have him guide us in using PowerShell in the day to day tasks we as administrators are tasked with, this book gives us the other side of the equation on WHY some of those scripts are the way they are. This book is specifically geared for V 2.0 of PowerShell, but what you take away from this book could easily be applied to V1.0 as well. I really enjoyed this book as it gives us the whole picture on where and why to use certain type of scripts. Just because we CAN make a huge script for something, should we? is there an easier or better way to do it? This is what this title brings to light. The book also goes into a bit more detail specifically on using and tying into WMI.
There are some known issues when trying to run login scripts on a Vista or Windows 7 machine. This is mostly due to our best friend and worst enemy UAC (User Account Control). Now the UAC is there to protect ourselves,… from OURSELVES! In it’s haste to protect us it can cause havoc when it comes to perfoming login activities like mapping network drives to your servers! An un-recommended method would be to diable or turn off the UAC. This puts a serious hole in the security model that Vista and higher systems leans on. Now this post is specifically for Printer mappings, but a better method is as follows, this can be done via local policy or network based GPO’s..
In your local policy object or the GPMC
Go to Computer Configuration – Adminstrative Templates – Printers
Locate POINT and PRINT RESTRICTIONS - Change Status from Not Configured to DISABLED
Click on to APPLY and then OK
Now logged off and log on as the User. You will now be getting the Printer mappings.