AaronBISSELL

In the event someone else comes across this, I managed to figure it out. The base MDT + SCCM Task sequence conditions on the Restore user State step was missing the condition Folder - %StateStore%\USMT exists by default. Once I added that condition, it then started running that step and the Refresh scenario is now working.

Hello Windows Noob family! I am attempting to a very basic, nothing crazy refresh from windows 8.1 to windows 10 using SCCM with MDT. I am doing a user driven installation with the latest ADK installation. I create a standard User Driven task sequence. Under the capture user state step I have Capture all user profiles by using standard options selected, with verbose logging and Copy by using file system access - checked continue if some files cannot be captured and capture locally using hard links. Then under Restore User state I am using Restore all captured user profiles with standard options. When kicking off the task sequence from within the OS, I have no trouble managing the wizard... which reboots me into WinPE and begins the image. I watch it run the USMT package which "Processes the User State". When the image is done, the user profiles are not restored, altho - all the data is still there under C:\StateStore. I can browse through that folder and see all the user profiles that were backed up, and all the content is there. It just appears to be skipping, or failing? On the Loadstate portion... I cannot find any scanstate / loadstate logs - and the SMTS.log files don't appear to display any errors. Any thoughts from the gurus here? Thank you!

I was leaning in the direction of a network issue... but I know if I cannot prove it, and I bring it to the network team - they're just going to throw it back on my plate!

Hello Windows Noob Community! I have an odd question that I am hoping the expert minds of this forum can help me remediate. My SCCM 2012 environment consists of 1 site containing 13 distribution points all over the world. I have PXE enabled at each location, which is working wonderfully. My issue is, randomly, at only 1 location - I will get image failures. As well, it's not all the time. I can image on the same exact port using the same exact computer 10 times and it will work 9 of the times. The failures usually happen about mid way through the imaging process, at random times within the task sequence. Some times after the OS install, it will fail to install any applications. Other times... it will install only a few of the apps and then fail. The logs all contain errors like this, when it happens... It looks like it tries a few times to connect to the distribution point but is unable to - and then results in failure. The error codes are actually pretty difficult to find solid information on...the errors in the majority of the forums I read always have 1 or 2 more items listed along with the error that helps point them in a direction. So, I was wondering if we could spark up a conversation and perhaps bring some resolution to my service desk teams who randomly struggle to image! The part that really bothers me... is that using the same port, same PC, and imaging one after another - I can get 1 that works, and 2 that fail - each failing in a different spot. Bleh Thanks!

I do agree - you should blog this, as it completely resolved my issue Thank you!

Hello WN community! I have a bit of stumper I was hoping to get some feedback on! Let me know what you think... Scenario: We're running SCCM 2012 now for a little over a year, problem free. We've noticed however, that randomly (about 10 out of 1000 clients) the SCCM Client is reporting that the PKI certificate is none. What's stranger still, is that in the ClientIDManagerStartup.log, it doesn't appear to have an issue detecting and selecting the PKI certificate... Directly after the client selects the Cert, the ClientIDManagerStartup.log fills up with this repeating for ages I have ran a repair on the client, same result. I checked to see if perhaps the clients were stuck in provisioning mode, and they're not. Sort of at a loss of what to check next! Any help would be greatly appreciated. Thanks

I had something similar happen after using the Scheduled Updates on my image - as well when I mounted the image via PowerShell to install and enable .NET 3.0 and 3.5 on our W8.1 image. I was able to resolve it by redistributing the Tools pack as well as the Settings pack. My poking around lead me to believe it was something with the unattend.xml file. After redistributing those tool packs, the image behaved as expected. Still not entirely sure why.

Well I got it working finally - and it turned out to be a bit more complicated than previously expected, so I will post sort of a "How To" on how to modify the ManagedBy and Description fields during OSD should anyone find any use for that. After first using the UDI Wizard Editor to add the page into the wizard, generating the OSDComputerDesc and OSDManagedBy variables, I then needed to develop the PowerShell to use those variables. Below is the code that ended up doing the trick. #Create OSD Task Sequence Environment Object $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment #Get the ComputerDescription $strComputerDesc = $tsenv.Value("OSDComputerDesc") #Get the ManagedBy Name $strManagedBy = $tsenv.Value(“OSDManagedBy”) #Computer Name $strName = $env:computername #Get PSSession Credentials $strUser = "Domain\OSD-Account" $strPassword = "Password" #Connect to Remote PowerShell Session #Set Active Directory Properties $pw = ConvertTo-SecureString -AsPlainText -Force -String $strPassword $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "$strUser", $pw $s = New-PSSession -Computer SERVER -Credential $cred Invoke-Command -Session $s -Script { Import-Module ActiveDirectory } Invoke-Command -Session $s -ScriptBlock { Set-ADComputer "$using:strname" -ManagedBy "$using:strManagedBy" } Invoke-Command -Session $s -ScriptBlock { Set-ADComputer -Identity "$using:strname" -Description "$using:strComputerDesc" } But before the PowerShell will work, there's a few steps that need to be completed. 1. The server that you're going to be establishing the PSSession with, needs to be enabled to allow the user account that's creating the connection - the rights to connect and execute commands. This is done by going to the server and opening an elevated PS Window and typing the code Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI This will open up a GUI "Permissions" window that you'll add the account being used to establish the connection with, and assign it Execute rights. 2. The account executing the code also needs the ability to modify the AD Computer Object Attributes "Managed By" and "Description. Since we're hard coding the account into the PS script (to avoid prompts), we need to make sure the account is limited to only being able to do what we want it to do. So the account that I used to establish the PSSession, I also Delegated Permissions over ONLY the ActiveDirectory OUs that the computer objects will be placed in, and gave it only rights to Read/Write to the specific fields we want. I opted to hardcode the credentials to an account with restricted permissions rather than create another field in the wizard to have the user enter credentials, because the creds would have to be passed in plain text in order for the PowerShell to read them (Which is why the OSDJoinaccount and OSDPassword variables won't work.) So now the wizard walks me through the set up, I fill in the description and managed by fields... And when it's all said and done, the machine is imaged, in the proper OU, with the description and managed by fields populated. I can now build reports / collections off these variables in SCCM.

The code run as plain PS Text Attributes modified with success Just strange... Does something about the OSD environment prevent this script from working?

Well after some work today I've had a few developments - that seemed to go okay, but ultimately I'm still stuck. The initial script wouldn't work because of a few reasons... 1. The ADComputer cmdlets only work if you're running the PS on a machine that has AD Users and Computers installed, and the features activated. 2. I needed to either install the features on every server during OSD, or use PowerShell to initiate a remote session and run the commands. I opted for the 2nd. Here is the script. #Create OSD Task Sequence Environment Object $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment #Get the ComputerDescription $strComputerDesc = $tsenv.Value("OSDComputerDesc") #Get the ManagedBy Name $strManagedBy = $tsenv.Value(“OSDManagedBy”) #Computer Name $strName = $env:computername #Connect to Remote PowerShell Session #Set Active Directory Properties $s = New-PSSession -Computer SERVERNAME Invoke-Command -Session $s -Script { Import-Module ActiveDirectory } Invoke-Command -Session $s -ScriptBlock { Set-ADComputer "$using:strname" -ManagedBy "$using:strManagedBy" } Invoke-Command -Session $s -ScriptBlock { Set-ADComputer -Identity "$using:strname" -Description "$using:strComputerDesc" } When I run this script on a machine, and replace the ComputerDesc, ManagedBy, and Name variables with static variables - the script runs off without a hitch. When I run it in the task sequence, it fails with this log entry. I have to leave for the day now, so I just thought I'd leave this hear to see if anyone had any thoughts.

And to note, the Computer Description doesn't work either Which is run by this command line in the same group

Hello Windows-noob community! I wonder if there's something you could help me with? The task: - Populate the "Manged By" attribute of a computer object during OSD What I have so far: - A custom page in my UDI Wizard as follows The managed by field has the OSDManagedBy task sequence variable populated for it - The PowerShell #Create OSD Task Sequence Environment Object $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment #Get the ComputerDescription $strComputerDesc = $tsenv.Value("OSDComputerDesc") #Get the ManagedBy Name $strManagedBy = $tsenv.Value(“OSDManagedBy”) #Computer Name $strName = $env:computername #Set the Active Directory Object Properties Set-ADComputer "$strName" -ManagedBy "$strManagedBy" Now, when fill in the strName and strManagedBy variables manually in the script, it goes off without a hitch. But I have it running right after the "Install Software" step in my task sequence and hence, the reason I'm here - it's not working. Any tips?

I use this in a report select Creation_Date0, Name0, User_Name0, AD_Site_Name0 from dbo.v_R_System where datediff(dd,Creation_Date0, getdate()) < 14 and Client0 = 1 I have a subscription to it that fires off every two weeks on a Monday so I can see who has ran an image / joined a PC to my domain

I see this forum isn't very lively. But it's the only place I know to go and post a question - so here it goes! I am trying to set up an exchange connector to monitor an email address in the cloud (Office 365) The setup - SCSM R2 Cumulative Update 2 - Exchange Connector 3.0 - EWSManaged API 1.2.1 I have copied the .dll files into their proper locations. Set up the exchange connector. And it completes with errors. The errors are... Exchange Connector: Failed to poll the inbox at https://outlook.office365.com/ews/exchange.asmxfor new mail, details: The request failed. The remote server returned an error: (401) Unauthorized. Exchange Connector: Unable to process email for BISSELLServiceDesk@bissell.com, message=The request failed. The remote server returned an error: (401) Unauthorized. I am just at a loss here and am moments away from opening a ticket with Microsoft. But I will put some faith in the windows noob community before I do. Any thoughts? Thanks

If you deploy the updates to a collection - without distributing them to the Distribution Points, you can check this box here to tell the updates to look to Microsoft Update