Don't forget, you can extract the Windows 7 iso onto a bootable USB. Makes the install much quicker:
1. diskpart
2. select disk 1 (if disk 1 is your USB stick)
3. clean
4. create partition primary
5. select partition 1
6. active
7. format fs=fat32 (ntfs also works).
8. assign
9. exit
10. Extract the ISO
11. xcopy d:\*.* /s/e/f e:\ (Copy Windows 7 iso content to the Flash Drive E:)
If you have access to MSDN, go grab it! Remember that your February Beta keys will still work. If you need to regenerate them then these instructions will help:
http://www.neowin.net/news/main/09/01/10/psstheres-how-to-get-your-windows-7-beta-key
The MMS09 State of the Union session revealed what the next version of SCCM will look like. The MMC is gone in favor of the Outlook-esqe toolbar (wonder-bar) as seen in SCOM 2007. It also requires Server 2008 64-bit as well as SQL 2008 64-bit. The other big piece of news is the elimination of ASP web reports in favor of SQL Server reporting services only. See all the screen shots and read more about it on Kenneth van Surksum's blog:
http://www.techlog.org/archive/2009/04/29/mms_2009_information_about_mic
SP2 for vista and server 08 have gone RTM. Additionally the block offering SP1 is being removed (your GPO to block SP1 will no longer work).
All the SP2 goodness can be found here:
A new feature being announced is XP mode for Windows 7. XP mode is essentially an application running in a Virtual PC virtual environment. Installing the application in the virtual pc environment will result in it being published to windows 7 as an application. The requirements for this technology includes processor virtualization support (Intel VT or AMD-V). It will be a separate out of band update released in final form to coincide with the release of windows 7 (so it's not actually built in). Paul Thurrott has a nice set of screen shots on the whole thing here: http://www.winsupersite.com/win7/xp_mode_pre_shots.asp
So our software licensing team asked about using SCCM's Asset Intelligence to track software license usage at our company. After going through all of our normal internal testing we were ready to import our xml formated license file into our site. However when we tried to import it on our production server we received a single message:
error
Unable to connect to the site database
Not very useful since my console and site server were obviously talking to the site database just fine. I spent many hours troubleshooting this one myself before calling Premier support. At which time I spent many more hours troubleshooting on the phone with them and fearing that the issue would be unresolved. We went through all kinds of troubleshooting of both my SQL server setup and my site server setup.
The only error message with any meaning behind it was when we tried to run the import manually:
D:\SMSPROV\bin\i386>mvlsimport.exe /file //server/share/MSLtest.xml
Failed to get Site Database configuration information.Failed to get Site Database connection.Failed to intialize.
Yes, those are forward slashes, per explicit instructions by Microsoft Support.
My gut told me it was a bug in SCCM, but how my site differed eluded both me and Microsoft support. Ultimately, by sheer luck a stumbled across the steps that would enable me to reproduce the bug on my own. My site had an unrelated hardware failure and I had to rebuild and recover it. As I rebuilt it I tried the import several times along the way, until it finally failed. Once I was able to reproduce the bug I let Microsoft know how my site differed from a working site. Turns out there is a bug importing the license file if the smsprovider is installed on another computer other than the site server. Support was then finally able to confirm that this was a bug that they could reproduce and would notify the development team. In the absence of an actual fix, they provided me with a workaround. The workaround is to export the sql node of the sms registry key from the site server and import it onto the smsprovider computer. If you are switching architecture you will have to update the key to compensate for wow6432node as well.
Export this key from your 32-bit site server: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\SQL Server]
Import this key into your 32-bit smsprovider computer.
Or, if your provider is 64-bit, find and replace \software\Microsoft\ with \software\wow6432node\Microsoft
Key will now be in this format:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\SQL Server]
Now import the new key onto your 64-bit smsprovider computer.
Following up on my recovery of a sccm site. My original recovery doc did not specify that during the wsus install, wsus needs to be setup to use its own custom website on ports 8530 (for http) and 8531 (for https). I later found that if you miss this step (When you notice your site fails to sync with its wsus database) then there is a simple utility installed with wsus that will allow you to change it. From the command line:
wsusutil.exe usecustomwebsite true
Also, if your site just isn't syncing for no apparent reason, I've found that a wsus reset may help:
wsusutil.exe reset
You can find wsutil on the wsus server in the program files\Update Services\Tools folder.
This weekend I installed the current windows 7 64-bit beta (build 7000). All my favorite apps installed just fine including the SCCM console. I even managed to find a beta build of the rsat tools: http://www.microsoft.com/downloads/details.aspx?FamilyID=82516c35-c7dc-4652-b2ea-2df99ea83dbb&displaylang=en The only thing that I spent a significant amount of work getting to run was google chrome. I'm still in love with it, and just started using the 2.0 dev beta. So of course I want to run it on top of my windows 7 beta. Well now you can. In the target part of your shortcut to chrome.exe add -in-process-plugins. It runs just fine now. Credit to: BlogsDNA
Oh by the way, windows 7 boots faster on the same machine I was previously running vista 64!
Despite the fact that Microsoft has recovery information posted in their online support docs ( http://technet.microsoft.com/en-us/library/bb680474.aspx), site recovery is still a confusing task. I've gone through several site recoveries and here are the notes from my last one, where the central site happened to fail. An important note that I don't think is explained very well is that you have to have a functioning site setup the same way as the old site before you can recover the old site.
So before starting the site recovery review the original site setup procedure. If you don't have one documented, then see the excellent write up by Ying Li: http://myitforum.com/cs2/blogs/yli628/archive/2008/06/25/setup-configmgr-2007-sp1-from-start-to-finish.aspx
Notes from recovery of Central site on 12/17/08.
1. OS, Server name, Site Code, and Drive layout (OS on C: and program files on drive d: ) should match original hardware. (Do not move from 64-bit to 32-bit OS).
2. Install the OS and configure as normal
3. Give the machine account admin rights on the SQL server
4. Install WSUS 3.0 with SP1. Do not use the default website. Use custom website. During install point it to the remote SQL server (if you use a remote sql server to host wsus metadata). Do not overwrite the contents of the database. Do not use the configuration wizard to setup wsus. Simply exit when the configuration wizard starts.
5. Start copying the backup files to the local machine since it can take 1/2 hour.
6. Install the correct version of SCCM
a. Make sure to reuse the same program path (d:\sms for our Primary sites since they were upgrades from sms. d:\sccm for our Secondary sites, since they were fresh installs when we set them up). This part is critical. When you do the recovery step, your site will to use the original setup paths that were in use prior to the site failure. Changing the paths will cause a significant headache!
b. On a new fully patched system you will not pass the prereq check. Double click on each item to see how to resolve the issue. You should be able to resolve every error.
c. After resolving the MMC sp3 issue, it will still show up as an warning in prereq check, that is fine if you are sure you have applied sp3 for MMC. The setup routine does not correctly query the registry to see that lastest version of the hotfix that Microsoft issued.
d. You can ignore the warning about SQL server authentication mode if you typically run SQL under the system account (without hardening SQL).
e. If you are attempting to restore a site that has a remote provider and point it back to the correct remote provider machine, the installer will complain that machine already has a provider.
1. On the provider machine, the registry key is blocking the install of the new remote provider, so remove the HKLM\SOFTWARE\Microsoft\SMS\Providers key.
2. On the provider machine, connect to root\sms with WBEMTEST and press the 'Enum Classes button'. No input is necessary, just press 'OK' to do an 'Immediate only' search. In the Query Results dialog window, click on the 'SMS_ProviderLocation' and press the 'Delete' key. Close out of all of these dialogs.
3. Delete the SMSPROV folder on the root.
4. Add the new site server machine as a local administrator and remove the old site server (if applicable).
Note: Provider fix, pasted from http://social.technet.microsoft.com/forums/en-US/configmgrsetup/thread/bb307748-7638-404d-a6a4-982827a051c8/
f. All other site servers will install the provider on themselves.
g. On the SQL DB server detach the old DB. Create a new DB with the same name and file locations. Give the smssite server db_owner on the db.
7. After the install has completed successfully run the site recovery wizard.
a. Close the console if open
b. Start>all programs>Microsoft System Center>Config Mgr 2007>Config Mgr Site Repair Wizard
c. Redsite and ROSsite do not have local DP's installed. Choose the option to skip package verification.
8. Reset permissions for site in AD.
a. Open AD users and Computers> System> System Management
b. Open properties and give site server full control on Systems Management container.
c. Open advance properties and change permissions so that they apply to "This object and all descendant objects" (this is not the default so be sure to do it).
9. Restore the site control file
a. Copy site_control_files sitectrl_<SiteCode>.ct0 to D:\sms\inboxes\sitectrl.box
b. Rename file from sitectrl_<SiteCode>.ct0 to sitectrl.ct0
10. After recovery perform a site reset
a. Rerun setup from Start>all programs>Microsoft System Center>Config Mgr 2007>
b. Choose site reset
11. Set user group permissions for recovered site and related site servers
a. Computer mgmt>local users and groups>Groups
b. Sms_sitetositeconnection_<sitecode> should contain the parent server and any child servers that need to connect to the site.
c. Sms_siteSystemtoSiteServer_<sitecode> should contain any parent or child site that needs to write to the site's DB.
d. Sms Reporting Users should contain any domain accounts that have reporting rights.
e. Sms admins should contain your sms administrators domain accounts.
12. If this was the central site with the wsus updates, then the wsus updates folders need to be reshared with the same share names. Check the software updates deployment packages nodes. On each package open the package properties. The general tab will show the share name that the packages is expected to be found on. The central site's machine account will need full control of this share.
13. Reset the wsus db:
a. From the cmd prompt: c:\program files\Update Services\tools\wsusutil.exe reset
b. Wait 1 hour
c. Force a Synchronization on the Update Repository
d. Verify wsus is syncing properly: wsyncmgr.log for errors.
14. Verify backup share permissions for newly restored site. Our backups are set for a share on another server, which is then backed up to tape. This can be verified in the site maintenance node and by reviewing the smsbkup.log located in the backup share.
15. If this was the central site, recreate the backup schedule for the site control file. A scheduled task that runs every 15 mins to dump the site control file and copy them to another machine:
a. site_control_file_backup.bat
D:\sms\bin\i386\00000409\preinst.exe /Dump
xcopy d:\*.ct0 backup_location\site_control_files /C /Y
16. Check and review system logs for errors for the next several days.
17. Monitor Site Status for errors. The only errors should be on the central site and be related to unapproved clients trying to get policy. Recheck in 24 hours.
18. Verify successful backups by reviewing the smsbkup.log located in the backup share.
