Apexes
-
Posts
140 -
Joined
-
Last visited
-
Days Won
6
Posts posted by Apexes
-
-
There's a software update that has been released for installing IE11 - i'd suggest pushing that out (assuming you use software updates)
Failing that, you can download the package and deploy traditionally through SCCM
-
As far as i'm aware, no you cannot integrate.
You can set approval on applications in catalog however
-
Looks as though it's an issue running the .bat itself.
Have you tried running the script manually on that machine and see if it errors out?
-
Sounds like IIS with all the HTTP errors.
Check out your IIS processes if not rebooted recently
-
What sort of task sequence is this?
When in the task sequence does it fail?
You really need to provide more information for anyone to help. smsts.log would be the best first bet to check out
-
You could use a task sequence and create variables for each option, upon validation of the hostname then tell it what command line to run for the package
That's assuming hostnames contain different identifier information
-
If you post the SMSTS.log we'll be able to get a better idea
-
What PXE error is showing on the client when it fails?
-
Have you deployed to a DP group that the troublesome DP was part of?
I've found this to be a bug before now, only way around it was to remove the group and re-distribute to all sites again
-
Setup a distribution point on site, enable PXE booting and have your content sent there through SCCM.
Setup relevant boundaries for your new DP and you'll be able to image on the network locally via SCCM PXE
-
That could be because when running as SCCM it'll run as the system account.
Not sure there's really a way for you to achieve this adding a currently logged in user.
-
execmgr.log & smsts.log on the client
-
I'm pretty sure you've got something going on with your machines not being a member of a domain after imaging, that'd explain why it's not populating site code automatically - so you'll probably want to take a look at that.
-
It's not asking for approval, that's just a generic message.
Log onto your distribution point and check sms_dp$\sms\smspxe.log for clues, when i've had this before it was one of two things.
- Boot image required re-distributing / one was missing on DP
- Restart the WDS service on your distribution point
-
1
-
-
You should have a timestamped clientlocation.log to give more information.
However - <![LOG[Local machine is not a member of an AD domain]LOG]!> is probably a good starting point.
Are you joining your machines to the domain as part of your imaging sequence?
-
Sounds like the environment has been in a bit of a mess with different versions and site codes installed everywhere.
When 1511 was installed, was this setup as a new site, and new site code, as opposed to upgrading an existing environment? Is it this environment site code that it's attempting to connect to first off when installing clients?
Difficult to tell where it's going wrong without being able to look into several other things on your setup, but if this was me... i'd uninstall all primary sites you've got, get shot of any records published, and start again with the SCCM version that you want going forward on a clean install. Obviously it depends on how setup your ConfigMgr is as to whether or not you can do that, but it sounds like you've still got records of that old site in AD and your clients are taking preference to that.
-
in your client settings, what do you have your client policy set to?
The polling of your client policy interval will determine when SCCM clients check in to the management point to receive new deployment instructions.
On that machine if you go into confiugration manager -> actions - you can run a machine policy retrieval & evaluation cycle, this will force it to run.
If you're seeing a delay even after doing that, do you have your client machine in a different time zone to your primary site server, and are you basing the deployment on local time or UTC?
-
For manual installations / client push you'd use that code, not necessarily in the task sequence as it should already properly assign the site.
This is probably a boundary issue - What does it say in your clientlocation and locationservices.log? have you checked that your site boundaries are applying to this machine in question?
-
haha, i've done exactly the same myself before now
Glad you spotted it
-
To the above message, it's SMSSITECODE=XXX
-
Check your client boundaries in SCCM to make sure they cover that client.
On the client itself, can you post its locationservices.log and clientlocation.log ?
-
We cannot help you until you post logs
-
Does your client push account in SCCM have access to this server to install the client?
-
post the smsts.log along with execmgr and appenforce.log if you're using the application models.
Without description of the errors it's difficult to help you
Multi-Site SCCM Infra Design Question - DPs
in System Center Configuration Manager (Current Branch)
Posted
1. How many clients do you have total, and do you need a CAS? I know MS recommends no CAS for anything below 100k clients, but i have seen companies using a CAS for a lot less. I've always gone for the single primary site with secondaries if required, and DP's where needed. With CAS you'll bring in a whole new dependency on DB replication across all sites - not that this is a bad thing, but i certainly saw a lot more issues with DB Replication links going down between a CAS and a primary, than what i did running a primary site with secondary's and DP's hanging off of it.
2. Only your business requirements can decided on splitting workload between sites - how many do you have?
3. SCCM Updates - Do you mean updates to SCCM infrastructure, or infrastructure on a whole? SCCM infrastructure should be relatively straight forward, if you mean the latter - I've managed servers and desktops all with software update management in SCCM on a monthly pattern.
Personally - I'd always push for one environment, any teams that you have doing work for separate regions/sites - bring in to one, and then you've got a standard across the whole business. I can see the benefit that separating the environment into sites which teams have their own access to can benefit - but i guess the question is, is that really needed, rather than applying these packages/admin just at the top level of one site.