How do I run Powershell.exe/command prompt as the LocalSystem Account on Windows 7?

How do I run Powershell.exe/command prompt as the LocalSystem Account on Windows 7?

Every once in a while I will need to troubleshoot something with the LocalSystem Account.  Using the Runas.exe command with "Nt Authority\System" doesn't work; I'm left trying to supply a password. I don't remember if it ever worked in WS2003.

C:\>runas /user:"Nt Authority\System" cmd.exe Enter the password for Nt Authority\System: RUNAS ERROR: Unable to acquire user password

There were a few ways to do this in the older Operating Systems.  The two I used to use were creating a scheduled task to run cmd.exe using the LocalSystem account and creating a Service to do the same thing.  However on Windows 7 these didn't work for me.  I tried a bunch of different ways but the way that worked the best was to launch Powershell.exe using PSExec.exe.

C:\>psexec -i -s Powershell.exe PsExec v1.97 - Execute processes remotely Copyright (C) 2001-2009 Mark Russinovich Sysinternals - www.sysinternals.com

This will launch a new window.

PS C:\Windows\system32> whoami nt authority\system

Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter, 2nd Edition

Free ebook: Understanding Microsoft Virtualization Solutions - Medium Sized Business Blog - Site Hom

blogs.technet.com

This free, yes, free 400+ page ebook Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter, 2nd Edition is the book for IT professionals who want to learn more about the latest Microsoft virtualization technologies, including Hyper-V and Remote Desktop Services in Wind

http://blogs.technet.com/b/mediumbusiness/archive/2010/10/27/free-ebook-understanding-microsoft-virtualization-solutions.aspx 

qUICKLY Explained: Active Directory Recycle Bin

To write something about AD Recycle Bin, the two things that we must understand first are

• 1. Difference between Authoritative and non-Authoritative Restore of AD
• 2. Tombstone Lifetime (TSL) - duration that allows all domain controllers to have the knowledge of an object getting deleted.

In the past (before 2008 R2 FFL and enabling AD Recycle Bin), there were two methods of recovering deleted objects in AD.

• Microsoft supported method of Authoritative Restore which required restoring AD database on a Domain Controller using a backup which contained the objects with the attributes you wanted to recover AND marking this object as authoritative using NTDSUTIL. (http://support.microsoft.com/kb/840001)
• Tombstone reanimation using LDP and changing the two attributes of deleted object i.e. isDeleted and distinguishedName (http://go.microsoft.com/fwlink/?LinkID=125452)

I am not going into the details of the above two methods as I am sure this is common knowledge by now. In terms of being able to recover objects from accidental or even intentional deletions in AD, Microsoft has provided a new feature called AD Recycle Bin. AD Recycle Bin requires that your AD environment is at Windows Server 2008 R2 Forest Functional Level and then you enable this feature (disabled by default) either by Enable-ADOptionalFeature PowerShell cmdlet or LDP.
Before you enable AD Recycle Bin, it's always good to know the gotchas. For example, once you enable AD Recycle Bin, you cannot disable it and after you enable it, your NTDS.DIT (AD Database) will grow by 10-20% on every Domain Controller in the forest. But another point to remember is that NTDS.DIT size may continue to grow as you delete objects. Why you ask? Simply because unlike before where all the attributes would be stripped except ObjectSID, lastknownparent, distinguishedName (DN) would be mangled and the object getting moved to the hidden Deleted Objects container, now the object becomes logically deleted which means the object is moved to the Deleted Objects container with its DN mangled only. A deleted object remains in the Deleted Objects container in this logically deleted state throughout the duration of the deleted object lifetime.  These objects can be viewed in LDP by enabling the Return recycled objects Control.
Deleted object lifetime is determined by the value of the msDS-deletedObjectLifetime attribute.  Tombstone lifetime is determined by the value of the tombstoneLifetime attribute. By default, msDS-deletedObjectLifetime attribute is set to null. When msDS-deletedObjectLifetime attribute is set to null, the deleted object lifetime is set to the value of the tombstone lifetime which in Windows Server 2003 and above is 180 days.
Hence, with AD Recycle Bin, you have 6 months to recover a deleted object with all its attributes as they were at the time of deletion, this is a huge advantage and benefit as you no longer need to find a valid, tested, recent backup of AD that has all the properties of an object at the time of deletion. For example, I have a user account that was added to a group and then deleted, the only backup I have is from last night which does not have this latest change of group membership so if I were to restore the user from my backup, it will not be a member of this group. AD Recycle Bin helps in this and you can all agree that this is absolutely a better solution of ensuring all properties are recovered which were present at the time of deletion. So AD Recycle Bin is a must have for Windows Server 2008 R2 FFL environments.
There are two attributes that need to be covered quickly in order to understand deletion of objects with AD Recycle Bin enabled. These attributes are:

• IsDeleted
• IsRecycled

When an object is deleted, the IsDeleted attribute is set to TRUE. Within the duration of msDS-deletedObjectLifetime, an object can be recovered and become a live object again. After this value expires, most of the attributes of the deleted object are stripped away similar to a deletion prior to AD Recycle Bin and also at this time IsRecycled attribute gets set to TRUE also. AD Recycle bin can only be used to recover a deleted object only when isDeleted = TRUE and isRecycled = False; this state of an object is called a Recycled Object (new state in Windows Server 200 R2). When both of these attributes are TRUE, the object is referred to as a Deleted Object. From this point on you cannot use AD Recycle Bin and to recover it now, you will have to use  Authoritative Restore procedure of a backup before IsRecycled was set to TRUE. This Recycled Object stays in Deleted Objects container for the duration of Tombstone Lifetime (180 days by default) and when this duration expires, a process called Garbage Collection (runs every 12 hours by default) physically deletes it from the AD database.
Hope this qUICK explanation helps M, Cheers :)

ORIGINAL POST FROM:
http://blogs.technet.com/b/qzaidi/archive/2010/10/23/quickly-explained-active-directory-recycle-bin.aspx

There’s a new DPM 2010 SCOM Management Pack

There’s a new DPM 2010 SCOM Management Pack - Welcome to the US SMB&D TS2 Team Blog - Site Home - Te

blogs.technet.com

The Microsoft TS2 Team blog is designed to provide insightful information for Microsoft Partners on the latest products including Virtualization solutions, Hyper-V, VDI, MDOP, and SCVMM. We also cover a variety of topics on Cloud Computing including, BPOS, Windows Azure, SQL Azure, CRM Online, and o

 Donwload LINK:::

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=32077d99-618f-43d0-843d-4ba4f8019f84&displaylang=en

Hyper-V R2 Live Migration

Reliability is one of the great payoffs to virtualization, and failover clustering has now got a whole lot better with Windows Server 2008 R2 and Hyper-V. Now, you get failover without any downtime for the virtual machine. Jaap Wesselius tells you how to implement it.
 
Windows Server 2008 Hyper-V offers a high availability solution by using Windows Server 2008 Failover clustering. The Virtual Machine is implemented as a cluster resource and when a host node fails, the Virtual Machine resource fails over to the other node. Like all other Windows Server 2008 Failover solutions, the resource is brought offline before it actually fails over. This results in a relatively small period of downtime which is unacceptable in certain environments.
Windows Server 2008 R2 Hyper-V offers a Failover clustering solution without any downtime for the Virtual Machine. This solution uses a new feature called "Cluster Shared Volume" or CSV and is called "Live Migration". In this article I'll explain what the CSV solution is and how it works.
Windows Failover Clustering
When creating a Highly Available Hyper-V environment, a Failover cluster needs to be created. A Failover cluster is a logical server consisting of two or more Windows Server 2008 servers. Windows Server 2008 supports a maximum of 16 servers in a Failover cluster.
These servers are called Cluster Nodes. All Cluster Nodes in the Failover cluster are connected to a shared storage solution where the data is stored. The Virtual Machines running under Hyper-V that need to be highly available are configured as a resource in the cluster.
Note. All servers in the cluster must run the same Operating System, all nodes must either be Enterprise or Datacenter Edition and for Live Migration all servers must run the same processor family (even the same processor stepping).
In a Windows Server 2008 Failover cluster, only one Cluster Node can be "owner" of the disk resource and only the owner of the disk resource can access the files (including the Hyper-V VHD files). Therefore, if a Virtual Machine needs to be failed-over to another Cluster Node, the complete disk resource needs to be brought down, moved to the other Cluster Node and be brought online again. The Virtual Machine is in a "saved state" during a cluster Failover. To bring the Virtual Machine in a saved state a certain amount of time is needed. For a Virtual Machine with only 256MB of memory this is only a short time, but a Virtual Machine with 8GB or 16GB can need up to minutes to be brought into a saved state. Starting the Virtual Machine on the new node will take the same amount of time. Needless to say, failing over a Virtual Machine can cause a significant downtime.

Figure 1. Two Hyper-V Servers in a Failover cluster, the Virtual Machine is stored on the Shared Storage
ESX Server has the functionality of migrating Virtual Machines from one Cluster Node to another without any downtime, and this always has been an issue with Hyper-V on Windows Server 2008. One of the highest priorities for Microsoft in Windows Server 2008 R2 was to add this capability.
In Windows Server 2008 R2 a new concept has been introduced: Cluster Shared Volumes or CSV. CSV offers the possibility for Windows Server 2008 R2 Cluster Nodes to access the shared volumes at the same time. As with Windows Server 2008, only one server can be the owner of the disk resource, but for Hyper-V, and only for Hyper-V, both servers can access the disk.
I say deliberately "only for Hyper-V" because other services cannot use the CSV option. If you use Windows Explorer to access the CSV disk you get an "access denied" error on the Cluster Node that is not the owner of the resource. So, when using CSV disk in the Hyper-V cluster, the need to Failover a disk resource when failing over a Virtual Machine has been removed.
What happens when failing over a Virtual Machine from one Cluster Node to another in the Hyper-V R2 cluster? When manually failing over the Virtual Machine, the configuration of the Virtual Machine is copied from one Cluster Node to the other Cluster Node. Then the Virtual Machine's memory is copied from one Cluster Node to the other Cluster Node, this happens online. But since the Virtual Machine is still running, memory pages keep changing. During a Failover, Hyper-V keeps track of the changed memory pages, so when all pages of the initial copy are on the other Cluster Node the changed pages are copied as well. This is an iterative process and is repeated until only a few changed pages are left on the first Cluster Node.

Figure 2. Copying memory pages from one Cluster Node to another and keeping them in sync
Then the Virtual Machine on Cluster Node 1 is shut down, the remaining memory pages are copied to Cluster Node 2 and the Virtual Machine on Cluster Node 2 is brought online. This happens in a fraction of a second and this process is fast enough that no clients will notice any downtime and is called a "live migration".
Note. This process happens during a manually initiated Live Migration. When Cluster Node 1 unexpectedly crashes, the Virtual Machine crashes as well. Cluster Node 2 will notice this and start (reboot!) the Virtual Machine. This does mean a certain downtime, but this situation is more or less the same for every vendor.
Building a Hyper-V R2 Cluster with CSV
To build a Hyper-V R2 Cluster with a Cluster Shared Volume and two Cluster Nodes the following prerequisites need to be met:
·        Two servers running Windows Server 2008 R2 Enterprise (or Datacenter) with Hyper-V and Failover clustering;
·        Each Server should have at least four Network Interfaces:
o        A Public Network for clients to access the Virtual Machine
o        A dedicated iSCSI network;
o        A heartbeat network;
o        A Management Network;
·        A Shared Storage solution with at least 2 LUN's. A small one (for example 1 GB) that'll be used as the Cluster's Quorum and a large one (for example 500 GB) that'll be used as the Cluster Shared Volume;
·        Sufficient IP addresses on the Public Network as well as on the iSCSI Network.
Install Windows Server 2008 R2 on both Cluster Nodes and bring them up-to-date with the latest hotfixes using Windows Update (or any other patch management solution of course). After Windows Server 2008 R2 is installed, open the Server Manager and install the Hyper-V Server Role. Reboot the server when requested.
When the Hyper-V Server Role is installed, an External Network needs to be created on both Hyper-V Servers. This External Network will be used by Virtual Machines to access the 'outside world'. On both Hyper-V Servers open the Hyper-V Management Console and click "Virtual Network Manager" in the Actions Pane. Select "New Virtual Network", select the Connection Type of External, and click Add to continue. On both Hyper-V Servers use the same name for the External Virtual Network, for example "Public Virtual Network". Connect this External Virtual Network to the Network Interface that is connected to the Public Network.

Figure 3. Creating the External Virtual Network
The next step is to configure two LUNs on the shared storage solution. In this example, the LUNs are 1GB and 500GB in size. Both LUNs need to be accessible for both Hyper-V Servers.
On the first Hyper-V Server, open the iSCSI initiator and connect the Server to both LUNs. Open the Server Manager and navigate to the Disk Management section. Bring both disks online (when needed), create two partitions and format them. Assign drive letters F:\ and G:\ to the partitions.
On the second Hyper-V Server, open the iSCSI initiator and connect the Server to both LUNs. Do not access the LUNs using the Server Manager, just connect the Server to the LUNs and that's it.
Using the Server Manager, install the Failover Clustering components (Failover Clustering is a Server Feature and not a Server Role).
When installed, on the first Hyper-V Server open the Failover Cluster Manager (which is located in the Administrative Tools menu). To check if your configuration is capable of creating a Failover cluster select the "Validate a Configuration" option in the Actions Pane. Run the wizard, enter both Cluster Node names and run all tests.
When finished an HTML report is generated showing the results of the validation:

Figure 4. The Failover Cluster Validation Report
When you've reviewed the Validation Report and fixed any issues when needed, it's time to create the actual cluster. In the Actions Pane of the Failover Cluster Manager select the "Create a Cluster…" option. When the wizard starts, add both Cluster Nodes, add the Cluster Name, and add the Cluster IP Address. When all variables are entered, the cluster is created by the Wizard. When finished, you have created your cluster, without any applications of course.
This is just an ordinary Windows 2008 Failover Cluster; we now have to add the CSV storage. In our test environment we have two disks:
·        One 1GB disk acting as the Cluster Quorum;
·        One 500GB disk that will act as the CSV storage.
After creating the cluster, the 500GB disk is just some storage in the cluster. When the Cluster is selected in the Navigation Pane, select "Enable Cluster Shared Volumes…" in the Actions Pane.

Figure 5. The Failover Cluster Manager. When the new cluster is selected you have the option to enable CSV in the Actions Pane
This will enable the Cluster Shared Volumes within your cluster. But since CSV is only available for Hyper-V a warning message is displayed. Check the "I have read the above notice" check box and click OK to continue.

Figure 6. Warning message since CSV is only available for Hyper-V
When finished, a new option appears in the Navigation Pane, the Cluster Shared Volumes. When you select this you can add the CSV storage. This should be an empty disk that's already in the cluster. Select the "Add Storage" option in the Actions Pane. Select the 500GB disk and click OK to continue. The disk will now be added as a CSV disk in the cluster.

Figure 7. The CSV Storage in the Failover Cluster Manager.
The CSV will not appear as a separate disk with a separate drive letter, but it will appear as a directory on the local C:\ drive, in this case C:\ClusterStorage\Volume1.
As stated before, the CSV storage will only be available for Hyper-V, although the CSV storage will appear on both Cluster Nodes at the same time. In Figure 7 you can see that CLUSTERNODE-1 is the owner of the actual disk resource. When you try to open Windows Explorer on CLUSTERNODE-2 it will fail, although you can see it in Windows Explorer. Using the CSV storage with Hyper-V Manager is not a problem though.
Using Hyper-V with CSV storage
To use Hyper-V with the CSV storage, the Hyper-V settings need to be changed. Both the Virtual Hard Disks as well as the Virtual Machines need to be configured to use the CSV storage.
Open the Hyper-V Manager on both Cluster Nodes and select "Hyper-V Settings…" in the Actions Pane. Enter the proper directory locations, for example:
·        C:\ClusterStorage\Volume1\Hyper-V\Virtual Hard Disk
·        C:\ClusterStorage\Volume1\Hyper-V

Figure 8. Change the Hyper-V settings to use the CSV Storage
Hyper-V is now ready to use the CSV storage and is able to Live Migrate VM's from one Cluster Node to another Cluster Node.
In the Hyper-V Manager, create a new Virtual Machine and make sure that it uses the directory as configured in the previous step. Configure the Virtual Machine as needed and continue the installation of the Virtual Machine.
After installation of the Virtual Machine, shut it down and open the Windows Server 2008 Failover Cluster Manager. Under the Cluster Name, select the "Services and applications" node and in the Actions Pane select "Configure a Service or Application". In the "Select Service or Application" pop-up dialog select "Virtual Machine" and click Next. Select the Virtual Machine that was just created and click Next two times. Click Finish to end the High Availability Wizard.
The Failover Cluster Manager now takes over the control of the Virtual Machine. To start the Virtual Machine right click it in the Failover Cluster Manager and select "Start". The Virtual Machine will now be started and after some time you'll be able to connect to the Virtual Machine.
To Live Migrate the Virtual Machine from one Cluster Node to another Cluster Node, open the Failover Cluster Manager and select the Virtual Machine. In the Actions Pane select "Live migrate virtual machine to another node" and select an available Cluster Node (CLUSTERNODE-2 in Figure 9).

Figure 9. Live Migrate a Virtual Machine to another Cluster Node.
Connected Clients will not notice that the Virtual Machine failed over to another Cluster Node!
Note. If you use a Private Network for Internal Cluster Communications, make sure that you've enabled the "Client for Microsoft Networks" and the "File and Printer Sharing for Microsoft Networks". If you do not enable this option, Live Migration of Virtual Machines will fail.
Conclusion
When using the Live Migration feature in Hyper-V R2, it is now possible to failover a Virtual Machine without any downtime, which was not possible in the first release of Hyper-V. The issues you have to be aware of are the Network Settings and the fact that Cluster Shared Volumes are only available to Hyper-V and not to any other service running on the Hyper-V server.
Management of the Hyper-V cluster will even be easier when using System Center Virtual Machine Manager 2008 R2, but that's beyond the scope of this article.

--
ANand
ఆనంద్ మోహన్ ఏలూరి
 ------------Windows Admin
Dream is not what u see in sleep, is the thing which doesn't let u sleep

The complete windows-7 shortcuts -ebook

http://www.thewindowsclub.com/the-complete-windows-7-shortcuts-ebook-released

 

Download LINK::

http://www.thewindowsclub.com/downloads/Windows7%20Shortcuts%20eBook.zip

Run IT on a Virtual Hard Disk – Test Drive Program,VMs should now be a little easier to find.

Run IT on a Virtual Hard Disk – Test Drive Program,VMs should now be a little easier to find.


http://technet.microsoft.com/en-us/bb738372.aspx


--
ANand
ఆనంద్ మోహన్ ఏలూరి
 ------------Windows Admin
Dream is not what u see in sleep, is the thing which doesn't let u sleep
my favourite: http://picasaweb.google.com/anand919
http://www.linkedin.com/in/anandme
http://www.brijj.com/anand-mohan-eluri

http://twitter.com/anand919

File server migration toolkit:

File server migration toolkit:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&displaylang=en
As with all servers, hardware gets old, outdated and needs to be replaced every few years. File server migration can be a chore; moving all the data is simple enough but what about the permissions and sharing status? Well this is where the File Server Migration Toolkit (FSMT) saves the day!

Administrators can use the FSMT to migrate all the data, along with the permissions and share status from one or more servers, to a server running Windows Server 2003. The tool is free, and simple to install. Once installed, open it up and you will be prompted to create a new project, or open an existing project. Select New and we are ready to proceed.



The New Project Wizard will start, click Next to proceed.



Give the project a name, and specify a location to save the log files too.




If you are using DFS, select the DFS root server, if not uncheck the box (more on DFS later). Click Next.



Select the location on the target server where the data is to be transfered to.



Click Finish to complete the wizard. We are now ready to add servers, click Add Server and enter the name of the source server. Repeat until you have all source servers listed.



On the right you will see three boxes. The first is pretty self explanitory, by ticking it, the shares on the source server(s) will become unshared once the migration is successful. The second box is also pretty straightforward, selecting it, copies all the security settings from the source server(s) to the target. The third box is a bit more indepth and I'll get to that in a bit.



Expand the server and you will see all the shares listed on the server. If it is a DC, you will not see the Netlogon or Sysvol folders. You can select or unselect the folders. The default target sharename is sharename_sourcename and the target location is [drive letter]:\sourcename. By selecting the source folder these options can be edited on the right hand side.



Click continue to proceed. The source server(s) will be analyzed and the details of the data migration will be detailed in the bottom right. Once you have verified the details, click Continue to proceed.



The files and folders will be copied from the source server(s) to the target.



Once complete, the next step is finalization. This is the process of copying any changed files since the project was created, as well as setting the security and share information. Another part of the process is the resolving of invalid SIDs. If you selected the Resolve invalid security descriptors check box when you set up the migration project, the wizard cleans up invalid security descriptors as follows:
• Deny ACEs with unresolvable SIDs, are replaced with the Everyone SID.
• Allow ACEs with unresolvable SIDs, the ACE is dropped.
• Audit ACEs with unresolvable SIDs, the ACE is dropped.
• An owner with an unresolvable SID, is set to the local Administrators group.
• A group with an unresolvable SID, is replaced with the local Administrators group.




The purpose of this is to ensure that the permissions set on the target folders are the same or more restrictive than they were on the source folders. One thing to note, if you did not select to "Stop Sharing Source Folders" they will continue to be shared even thoug that message states they will not. Click Yes to continue. Once complete, you will be notified the process is complete.



If you are using DFS, the DFS Consolidation Root Wizard will lessen impact of file server consolidation on end users by keeping the original Universal Naming Convention (UNC) path of files after they are migrated to the target server. Because the original UNC paths are kept, you do not need to worry about new server names, shortcuts and OLE links in files. All these will remain functional after the files are moved.

Saving and restoring existing Windows shares

http://support.microsoft.com/kb/125996


File Server: windows share migration
You have a Windows File Server and you want to migrate the windows shares. What options do you have to complete this job? A) recreate them or B) migrate them from ServerA to ServerB. Sometimes option A is the only one you have but in most cases you want to keep those Windows Shares available as they were before and using some kind of script would be nice. Microsoft published a KB125996 article based on following procedures and my option B:


• Reinstall Windows over an existing installation (a clean install, not an upgrade).
• Move all of your data drives from one server to another.
• Install Windows to another folder or drive on a computer that already has Windows installed.
I am performing a clean installation of a application server which has several file shares associated for application functionality. I don’t want to recreate them manually and I am using the next steps to complete this task.
a) Verify the shares you want to migrate and the drive letter location is the same on both servers.

b) Export the Shares key from HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
reg export HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares LanmanServer.reg

c) Make sure the user and group still exist in the domain! When migrating from DomainA to Domain B make sure you recreate all users and groups. Copy LanmanServer.reg to ServerB and import the registry file.
reg import LanmanServer.reg
net stop server & net start server

Reboot the file server and verify the share with “net share” command; also check the System Eventlog for any warnings or errors.

How to Migrate from IIS 6 to IIS 7

http://blogs.iis.net/bills/archive/2008/06/18/how-to-migrate-from-iis-6-to-iis-7.aspx

Ten Best Practices / Troubleshooting Tips with Process Explorer Tool

http://www.msigeek.com/6229/ten-best-practices-troubleshooting-tips-with-process-explorer-tool

System Center Configuration Manager 2007 R3

System Center Configuration Manager 2007 R3 unleashed! - Nexus SC: The System Center Team Blog - Site Home - TechNet Blogs

Microsoft Assessment and Planning Toolkit

http://lnkd.in/MiUJmb