Jump to content


ScriptingIT

Established Members
  • Posts

    11
  • Joined

  • Last visited

Posts posted by ScriptingIT

  1. So that was not a hard POC. Here is some untested autoit code you could run like this:

     

    CheckFileExists "C:\Program Files\My File\MyFile.exe","::Sensible name or task, where we are in the sequence, thanks for all the fish::"

     

    And you would get a centralised log showing where that machine is in the process and some time stamping etc. That's my kind of logging, really basic. Code would need error trapping, testing etc. AutoIT compiles to an EXE (password security). 10 lines of autoit to better SCCM/OSD logging (in terms of seeing useful info while machines build).

     

     

    Dim $Octecs[1]

    If $CmdLine[0] < 2 then MsgBox(0,"ERROR","You need to call " & @ScriptFullPath & " with " & chr(34) & "LOG ENTRY,FILE TO CHECK FOR" & chr(34))

     

    $2Log = $CmdLine[1]

    $2CheckExists = $CmdLine[2]

     

    DriveMapAdd ( "Z:", "\\server\share",0, "domain\user", "password")

     

    If FileExists($2CheckExists) Then

    FileWriteLine("Z:\Logs\" & @IPAddress1 & "_" & @ComputerName & ".txt","Checking for file:" & $2CheckExists & @CRLF & $2Log & @CRLF & " ERROR:File does exit")

    Else

    FileWriteLine("Z:\Logs\" & @IPAddress1 & "_" & @ComputerName & ".txt",$2Log & @CRLF & " SUCCESS:File does NOT exit")

    EndIf

  2. In the end it was just easier to write a simpler deployment toolset and do our own logging so I'm not likely to do this if anyone else wants it. Anyweb feel free to just delete it.

     

    The issue here is not the tool (that is simple) its the translation table (that's to big a job for google half the time). Still there are some that could be captured and usefully shown with some set comments. Run a script at the end of critical task sequences that checks, maps a drive, and logs centrally to it would probably be better. Create the log as something like:

     

    COMPNAME_LASTUSER_IPSUBNET.txt.

     

    The computers name can be read from the local REG in PE (and last user or newest user profile dir etc). Mmmmm.

  3. I'm not sure which assumption to deal with first. We are a team with plenty of redundancy and our client get handover so most (not all) have internal people who can operate the solution.

    We are not re-inventing the wheel as the wheel you refer to is more a wheel template. That wheel template in fact does not do many things we (and our clients) need and therefore we created a wheel that does.

     

    Rather than buy just some software template you can by support from us and we can use and BDD and up light touch, SMS or SCCM. But if you want all some of the feature that solution does not have or cannot easily be adapted to give that ours can we have our toys also.

     

    Our toys can leverage any system and work with it or work on their own. You can leverage us and well run whatever it is or casually consult etc. I'm not selling mind we are nicely at capacity and taking on work as we can manage it (not much point marketing).

     

    Large companies tend to operate in small groups at the client coal face. We are just like one of those groups focused on SOE, packaging, deployment, etc.

     

    Clients tend to be 400 - 4000 space for us but really it makes little difference for deployment and even SOE (few more apps, big deal). I try not to get owned by a solution mind.

     

    I'm not sure if I'm being difficult or if you are unreasonably focused one a single technology when the outcomes of SOE and its management are more diverse than one solution can hope to offer (unless you can touch the dev team, have them on contract and order up some new 'toys for less').

     

    Oh and don't get me started on the logging of all those systems, where SCCM stores packages by default, how slow the interfaces are, etc, etc, etc.

     

    I thought in fact your troubleshooting page (just for your reference one) was a poster child for how bad logging and troubleshooting MDT/SCCM/WDS etc really are (I know I've started). Still we design, build and manage them and keep them working. I forwarded to some of my team mentioning how good your guides are and how amusing that page is (we can all relate to it).

     

    More and more I am of a mind to replace it (SCCM) with something simple (I mean 4000 clients is not a lot and its not spread across the USA). I don't see anything simple so we created our own. It actually is simple. Thanks not an assumption, I've seen it and we work with both. It is all about client needs and not a specific technology. In this space that is the last of their troubles because they all work or they would not exist.

     

    Hope that explains it. ScriptingIT world famous in some parts of New Zealand.

     

    no I don't work for Microsoft, I work as a Technical Consultant for Logica,

     

    my point is simply this, why re-invent the wheel when there are solutions out there already, plus any custom solution you figure out will only be supported by you and no one else,

  4. Did you read my post?

     

    We work a lot with SCCM and MDT, and as stated provide and manage solutions using both. When you get familiar enough with a product its common to start seeing it as really EASY. Its OK, I guess (they all are if run well). If you know your stuff and your clients though you can make life for them and yourself much simpler again. I'm not selling anything but I think I've enough experiance of the various technologies to still have an opinion. SCCM is just a framework, not the second coming. It is easy for us, we make it easier for our clients. Do you work for MS?

     

     

     

    well i'm sure what you are doing makes sense to you but seriously if you want to ease your own pain then look at MDT 2010 using task sequences so its EASY even for a customer, it will do all of those things and more for free, much less need to script things and hack isos/winpe.

     

    SCCM is just the icing on the cake and well, then some :)

     

    cheers

    niall

  5. All fixed now!

     

    Issue 1 is you cannot copy a WinPE3.0 ISO (generated using the WAIK) to say C:\MyIso.iso on a Windows XP machine and get that machine to reboot to that ISO (like you can with older WinPE2005 iso's using the process I described in another thread on this site). That is because the new ISO's are actually just wrappers that load a WIM into memory and the method we use actually loads the ISO into memory (hope that makes sense).

     

    The second issue is if I use an old PE iso that does work (I can boot from the local ISO as normal) but Diskpart and Format create a NTLDR boot loader. I tried running the later DiskPart but it does not work under PE2005. I tried Bootsect.exe but it gave errors also.

     

    In the end I copied the new PE3.0 System32 dir to a network share and from the PE2005 (which maps M: below that share) ran Bootsect.exe and it worked and set the bootloader to NT60. Now it all just works again.

     

    What does this mean? It means I can deploy our system from SMS2003 or any deployment system and it can rebuild XP to Win7 remotely without having to pay for SCCM cals, add mac addresses to databases, set machines to PXE boot as the first option etc, etc.

     

    We are AutoIT lovers so from PE2005 (again booting to that ISO from the local C:\ in XP) like this:

     

    Map M from PE2005

     

    RunWait(@Comspec & " /c " & "diskpart.exe /s M:\scripts\diskpart_pe.txt",@TempDir,@SW_HIDE)

    RunWait("cmd /c Format c: /fs:NTFS /v:""CDisk"" /Q /Y",@TempDir,@SW_HIDE)

    sleep(1000)

    RunWait("cmd /c m:\Tools\CDTools\PE32Dir\bootsect.exe /nt60 /f c: >> c:\temp\ScriptingIT\BootRect_Log.log","m:\Tools\CDTools\PE32Dir\bootsect")

     

    Run ImageX and drop down your Win7 Wim

    Copy down the drivers for that model (and hardware based installs etc)

    Inject them

    Update the XML

    Drop in some non-base optional apps etc

     

    Much as I like SCCM not all our clients have it or plans to have it but they want to deploy Windows 7. Even where we do have SCCM I still tend to use our system because its easier for all concerned (NZ not all clients have a SCCM expert about our stuff is really simple to drive). Also we can send driver zipped packs to clients they just pop them in a DIR and ZAMMO another supported model etc.

     

    We can still use WDS if needed and all that but we are free (insert manic laughter here) from CAL's and mystically knowing MAC addresses of new machines etc.

     

    Having said all that SCCM is still pretty cool and the guides here made is MUCH more useable for me (and I live in it at times and date back to BDD2.5). SO APPRECIATE the time you've spent! Makes me want to contribute more.

     

    If you have never booted XP from a local ISO check out the other thread it is really quite useful at times (or in our case all the time on various sites).

     

    are you saying with issue 1 that you cannot boot winpe 3 ? i'm not following you exactly...

  6. This one has been entertaining me for days...

     

    We like to use our own systems for Windows 7 rather than SCCM/MDT for some clients as we add a lot of features and can hand it over with less training.

    Still there is an issue when rebuilding XP machines to Windows 7 (trying to do this the way we currently rebuild XP to XP).

     

    Like my other post on this site we set an XP machine to boot from a CD ISO then reboot and from the CD image drop down the WIM, provision/move the Comp AD account etc.

     

    Issue1: You cannot use a PE3.0 ISO to boot XP from the local ISO (the boot from local ISO loads the ISO into memory but 3.0 ISO actually contain the WIM which they then load to memory so that does not work)

     

    To solve this I just created a good old PE2005 ISO which maps to the netork and kicks off the process. I changed all the logging to a network share (as there is no ability to write to X: in PE 2005).

     

    Issue2: If I Diskpart and Format the disk in PE2005 then load my WIM and reboot it gives me "NTLDR is missing" as in the MBR is XP because we Diskpart with PE2005 even after dumping down our WIM. I noted that BCDEDIT seems to run fine from PE2005 so I did an export on a PE3.0 CD (post diskpart/format/wim drop) and tried to import that under PE2005 post diskpart/format/wim drop. It said "success" but still gave NTLDR missing.

     

    Any ideas on this one would be nice. What we tend to do is create a SMS job that sets the remote machine to boot from the local ISO then reboots it, the iso does the rest. Sadly here I either cannot boot the PE3.0 ISO this way or cannot format the disk to suite Win7.

     

    I did try running the later Diskpart under PE2005 but it does not want to run it (invalid 32bit application).

    Any ideas would be good or I'll post back once I crack it.

  7. So many good bits of info on this site. I'll try add at least a few things given I've received plenty.

     

    I work with a small team that creates our own build solutions or uses the various MS ones. We are all scripter's and create a mad range or desktop management things all the time.

    There is no deployment without packaging and scripting. In fact I think those two areas are primary. Then there is post deployment management and keeping an SOE in line with the fleet (lots of work in that space).

     

    We are big fans of the SOE process though and Windows 7 makes it Christmas for us! Better than the Y2K scam (go Office Space).

    Where we have to work with SCCM and MDT natively I think it falls down around the logging most specifically (and pain in handing over to non-specialist BAU). There is no more one SCCM/OSD implementation than there is one Linux.

     

    MDT being so power shell scriptable is interesting.

     

    Fav technology, AutoIT - great tool I would hate to have to automate without it (HTA's/VBS are a true last resort for me now days) Powershell is a real upgrade to VBS.

  8. I've been booting from local ISO's for years but I can never find instructions when I search for how to do it. Perhaps there are loads of these guides out there but just in case here is another.

    First up so I can find this again.

     

    Boot XP from local ISO

    Boot from iso stored locally

    Boot from c:\winpe.iso

     

    There is nothing like the smell of dirty old batch files in the morning...

     

    Extract the attached ZIP to C:\Temp\PELoaders

     

    Copy your ISO file to C:\ and call it winpe.iso

    NOTE: sadly this cannot be a PE3.0 iso as that just load a wim into memory and this process loads the iso into memory it just does not work

    If you do get this working let me know (you see the prob, this loads an iso into RAM which loads a WIM into RAM... earlier PE's and lots of others (bart) work fine

     

    You can run all this in Windows (I suggest a test machine incase you never manage to boot up again which is likely enough for a first go).

    Run these commands in a CMD (while live in Windows XP, again TEST MACHINE!)

     

     

    ATTRIB c:\ntldr -S -H -R

    copy c:\ntldr c:\ntldr.OS

    copy C:\Temp\PELoaders\ntldr.PE c:\ntldr

    ATTRIB c:\NTDETECT.COM -S -H -R

    copy c:\ntdetect.COM c:\ntdetect.OS

    copy C:\Temp\PELoaders\ntdetect.PE c:\ntdetect.com

    ATTRIB c:\winnt.sif -S -H -R

    del c:\winnt.sif

    copy C:\Temp\PELoaders\winnt.pe c:\winnt.sif

    ATTRIB c:\ntldr +S +H +R

    ATTRIB c:\NTDETECT.COM +S +H +R

     

    That Winnt.sif is a pre confirgured file looking like this: (so you iso needs to be c:\winpe.iso or you can change this file to suite - only x86 tested)

     

    [setupData]

    BootDevice = "ramdisk(0)"

    BootPath = "\i386\System32\"

    OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=winpe.iso"

    Architecture = "i386"

     

    If at this point you realise this is not a test PC and I want to go home you can set everything back to booting from XP (or you do this in XP having just booted there using this method) and run

     

    ATTRIB c:\ntldr -S -H -R

    ATTRIB c:\NTDETECT.COM -S -H -R

    del c:\NTLDR

    del c:\NTDETECT.COM

    del c:\WINNT.SIF

    REN C:\NTLDR.OS NTLDR

    REN C:\NTDETECT.OS NTDETECT.COM

    ATTRIB c:\ntldr +S +H +R

    ATTRIB c:\NTDETECT.COM +S +H +R

     

    The boot files are Windows 2003sp1 files. Note the websites below show how do download an eval copy and extract them.

     

    Rebooting a remote machine to PE is useful. Add some tools like VNC server and you can then remote it and do AV scans, kick of deployments etc. Rebooting your own machine to PE locally is good to. This is part of our framework for 'Zero touch' for Windows XP. Now in Vista and 7 we can all boot from WIMS which is good when working with PE 3.0.

     

     

    After searching for winnt.sif and ISO I found some posts on this (seems everyone does it differently by the process here has worked for me for ages -only not with WinPE 3.0-).

     

    http://www.911cd.net/forums/index.php?showtopic=10445

    http://www.911cd.net/forums/index.php?showtopic=10482

     

    After seeing all the useful stuff from Anyweb it seemed time to try contribute something useful though this one might we widely known I can't find it myself. The ones above confuse me.

    PELoaders.zip

  9. The lastest SCCM/OSD is the best it has been but it still has a number or obvious issues and always has. I'm tempted to work on a few and thought I'd start here (might be already done after all).

     

    Problem 1

     

    The worst problem IMO is logging for several reasons:

     

    It changes location all the time (well three times and it's not that hard to follow but it is still a pain in general)

    For every 10 lines of logs if you are really lucky one might be useful (so many repeats or overly verbose logging)

    Often the useful lines of log need to be decoded with google, and sites like this

    The logs are way to cryptic

    The logs do not include a lot of useful data (poor usersname or password for mapping drives say)

    The logs lack documentation (nice flow through guides for typical builds and lookups on everything)

     

    Tool 1

     

    So I wondered if I could be motivated to write a tool that watches the logs (even as they move) and just translates some of the significant events. It might read from an ini so those events can be added over time and in phases.

    It could run at the different stages just watching the log with a "show logs" button maybe.

     

    Another tool might just read the events out of SCCM's System Status, deployments advert, just flow through logs for a single machine. These logs are quite useful but I find viewing them could be a lot better (but then there might already be better ways).

     

    Anyone interested or has done or seen something similar?

  10. I really just signed in to say thanks for sharing all that effort. I've read loads of your posts now and followed various guides. Makes me think I should be contributing more also.

    I might give that more of a go here. So thanks again and really well done.

  11. I think I've seen that before but I don't remember the details. There are some very good SCCM deployment guides here and the MDT documentation has a pretty decent quick start guide for SCCM deployments. I think that issue could be a number of things and you need to go through the guide and check all your settings (or start over). Otherwise you need more details. Did it ever work (if not recreate with guide) if so when does the error occur. Can you attach the log files (log locations in the guides).

     

    Good luck.

     

     

     

    Hi

    I have a problem : after capturing a reference machine windows 7, i deploy this image with sccm and ihave this error message "Windows could not finisg configuring system. To attempt to resume conffiguration, restart the computer" and after restart always same error message.

    any help please.

    I captured image with task sequence media.

    think you

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.